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INTRODUCTION 


The  first  international  conference  on  PCTE.  PCTE  '91.  was  held  in  The  Hague  from  25  to  27 
September  1991.  PCTE  '91  was  supported  by  the  three  main  organisations  involved  in  PCTE. 
These  are  the  European  Computer  Manufacturers  Association,  Technical  Committee  33  (ECMA 
TC33),  the  Independent  European  Programme  Group,  Technical  Area  13  (lEPG  TA-13),  and  the 
CEC  established  PCTE  Interface  Management  Board  (PIMB).  The  conference  was  organised  by 
the  TNO  Physics  and  Electronics  Laboratory  (TNO-FEL). 

Nowadays,  it  is  widely  accepted  that  the  use  of  software  engineering  tools  (CASE-toolsO  is 
necessary  to  master  the  growing  complexity  of  software  production.  The  support  provided  by 
these  tools  is  needed  during  the  whole  software  life-cycle,  from  initial  requirements  capturing 
until  maintenance.  To  gain  full  benefit  of  this  tool  usage,  tools  have  to  be  integrated  into  a  so- 
called  Integrated  Project  Support  Enviroiunent  (IPSE).  The  Portable  Common  Tool  Environment 
(PCTE)  is  a  set  of  software  services  required  to  build  EPSEs.  These  services  support  the 
integration  and  portability  of  tools.  A  good  introduction  to  the  concepts  of  PCTE  is  given  in  [1]. 

PCTE  '91  showed  that  PCTE  is  gaining  wide  acceptance.  This  was  not  only  illustrated  by  the 
large  number  of  attendants  (about  160  from  16  countries  in  Europe,  North  America  and  Asia),  but 
also  by  announcements  made  by  several  major  platform  suppliers  (Digital,  HP  and  IBM). 
Furthermore,  a  large  number  of  CASE  tool  vendors  discussed  tlie  use  they  are,  or  will  be,  making 
of  PCTE.  The  conference  lasted  three  days,  each  day  was  targeted  at  a  different  audience.  The 
first  day  was  targeted  at  decision  makers,  the  second  at  application  builders,  and  the  third  at  tool 
builders. 

This  report  contains  an  account  of  the  presentations  given  at  the  conference.  This  account  is  based 
on  the  speakers'  overhead  sheet  presentations  and  the  authors'  personal  notes.  Copies  of  the 
overhead  sheets  were  handed  out  at  the  conference.  Each  chapter  of  this  report  contains  the 
presentations  of  a  particular  day.  Attached  to  this  report  are  three  appendices.  The  first  af^ndix 
comains  the  actual  program  of  the  conference,  the  second  appendix  lists  the  attoidants  actually 
present  at  the  conference.  The  last  iq)pendix  contains  the  full  text  of  the  conference  opening 
address. 


^CASE  ”  Compuier  Aided  Software  Engineeiinc 
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2  DECISION-MAKERS'  DAY,  WEDNESDAY  25  SEPTEMBER  1991 

On  the  first  day  of  the  conference,  the  D»:ision-Makers'  Day,  the  conference  was  opened  by  Mr 
Spohr,  Director  of  TNO-FEL.  The  oi:ganisations  involved  in  PCTE  presented  their  motivations  to 
support  PCTE-related  programmes.  During  the  session  on  Industrial  PCTE  Strategy,  major 
platform  suppliers  revealed  their  PCTE  strategy.  Several  of  the  speakers  of  this  day  participated  in 
the  panel.  The  Decision-Maker's  Day  was  concluded  by  a  management  introduction  to  PCTE. 


2.1  Opening  Address 

Speaker:  Mr  P.  Spohr 

PCTE  *91  was  opened  by  Mr  Spohr.  Director  of  TNO-FEL.  In  the  opening  address  he 
distinguished  three  kinds  of  open  systems;  Proprietary  (P  type),  De  facto  (D  type)  and 
Standardized  (S  type).  PCTE  clearly  is  an  S  type  of  open  system.  Apan  from  the  advantages  that 
open  systems  can  offer  a  tool  user.  Mr  Spohr  also  identified  several  (sometimes  forgotten) 
advantages  open  systems  can  offer  a  tool  supplier,  less  risk  at  product  intnxluction,  a  larger  initial 
market,  and  stability  of  that  market  He  concluded  his  talk  by  stating  the  user  requirements  that 
emerged  from  a  discussion  about  the  introduction  of  a  standard  CASE  tool  at  TNO-FEL.  The 
requirements  were:  portability  of  tools,  similarity  of  user  interfaces,  support  for  different  methods, 
interoperability  of  tools,  and  support  for  teams. 

The  complete  text  of  the  opening  address  is  attached  to  this  report  as  Appendix  C. 


2.2 

Organizations  behind  PCTE 

2.2.1 

PCTE  Standardization 
Speaker:  Mr  Myer  Morroo 

Mr  Morron  (BNR  Europe  Ltd),  the  chairman  of  ECMA  T(r33,  gave  an  overview  of  past,  present 
and  future  of  PCTE  standardization.  Furthermore,  he  gave  a  personal  view  of  the  positive 
achievements  as  well  as  some  negative  aspects  of  ECMA  TC33.  He  concluded  his  talk  by 
pointing  out  that  currently,  PCTE  is  really  entering  the  exploitation  {Hiase. 

Mr  Morron  divided  the  evolution  of  PCTE  into  four  periods.  During  the  first  period,  1983-1986, 
the  concciHs  underlying  PCTE  were  developed  in  the  CEC  Esprit  project  32.  This  project  led  to 
the  PCTE  1.4  C  Specifications.  During  the  next  period,  1986-1988,  the  iq^licability  of  PCTE  was 
broadened  in  the  lEPO  TA-13  programiiM.  Within  this  {MOgramme  PCTl^  Issue  3  was 
developed,  which  was  based  on  the  PCTE  1.S  Ada  and  C  bindings  developed  under  the  auspices 
of  the  PIMB.  During  the  next  period,  1988-1991,  PCTE  was  standardized  by  tfie  ECMA.  Until 
ru)w  the  Abstract  Specification,  ECMA  149,  as  well  as  the  C  language  binding,  ECMA  158,  have 
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been  standardized  by  ECMA.  In  the  near  future  an  Ada  binding  (December  1991)2  and  a  C-h- 
binding  (June  1992)  will  be  standardized.  However,  the  date  for  the  C*h-  binding  is  rather 
optimistic.  One  of  the  major  problems  in  the  development  of  this  standard  is  the  absence  of  a  C-m- 
language  standard.  The  last  period  in  PCJTE  evolution,  which  started  in  1991,  must  lead  to  > 

international  standardization  in  ISO.  Depending  on  siq>port  widiin  ISO  the  fast  track  will  be 
followed.  However,  no  risk  will  be  taken  in  order  to  prevent  any  possibility  of  rejection,  since  this 
would  devalue  PCTE. 

Mr  Morron  thought  the  TC33  programme  had  achieved  several  positive  points.  It  produced  i; 

several  high-quality  standards  and  carried  Open  Systems  to  higher  levels.  Within  the  programme 

natural  conflicts  in  members'  business  interests  were  overcome.  Moreover,  good  personal,  *  r* 

business,  and  technical  relationships  were  created.  The  programme  established  European  R&D  in 

Software  Engineering  Standards  and  brought  together  Civil  and  Defence  interests  as  well  as 

Government  and  Industry  interests.  On  the  negative  side,  Mr  Morrem  experienced  that  it  was  very 

dilTicult  to  get  ermugh  resources  for  the  work.  He  stressed  that  it  was  important  to  have  a  strong 

team  in  place  to  carry  work  forward  via  ISO.  Furthermore,  he  regretted  that  there  was  still  no 

good  introduction  to  ECMA  PCTE  available. 

Mr  Morron  concluded  his  talk  with  pointing  out  that  PCTE  is  really  coming  entering  exploitation 
phase; 

PCTE  is  supported  by  all  major  platform  suppliers  (IBM,  DEC.  H-P,  Sun,  and  Bull); 

many  toolsets  are  under  develoinnent  (EAST,  Enterprise  II,  HyperWeb,  and  Concerto); 

major  tool  suppliers  are  interested  or  active  in  PCJTE,  (CADRE,  IDE,  MARK  V,  and 

MENTOR);  i 

PCTE  is  considerably  influencing  US  DoD  activities  (AJPO,  STARS,  and  PCTS). 

In  this  respect,  Mr  Monon  found  the  recent  announcernem  of  the  US  Departmem  of  Commerce  -  ^ 

National  Institute  of  Standards  and  Technology  (NIST)  very  important.  On  3  September  1991  it 
was  announced  that  NIST  {Hoposes  to  use  the  ECMA  PCTE  specifleation  as  the  basis  for  the 
development  of  an  integrated  set  of  ISEE  PTI^  standards.  According  to  Mr  Morron,  this 
announcement  will  have  a  great  impact  on  the  availability  of  PCTE  from  US  developers. 

1.13.  Why  PCTE  for  Defence? 

Speaker:  Dr  Brain  Gladnaa 

Mr  Gladman  (MoD  UK),  chairman  of  lEPG  TA-13,  described  the  rationale  behind  the  lEPO 
TA-13  programme  and  the  work  undertaken.  Mr  Gladman  pointed  out  that  many  defmee  systems 
now  depend  on  computers  and  hence  software.  However,  software  intensive  defoice  projects 
frequently  tvm  into  difflculties.  Since  software  engineering  is  at  present  still  an  immature 
discipline,  investment  in  technology  assessmou  and  (tononstration  is  needed. 

2tIn  Ada  laagiMS*  binding  for  PCTE  wuMoepiedu  an  ECMA  HMidtre  (ECMA  169)  by  ihtOemnl  AuemUy  of  Dmnibcr  1991  ) 

^ISBE  ■  bu^mad  SoAann  Enginaoiiv  Bnviranmant 
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Because  high  capability  software  tools  are  veiy  costly  to  develop,  the  investment  needed  can  only 

be  sustained  by  a  large  market.  A  common  tool  interface  is  a  way  of  generating  such  a  large 

market.  PCTE  was  selected  as  common  tool  interface,  since  a  civil,  international  standard  was 

thought  to  be  essential  to  obtain  the  benefit  of  a  large  commercial  maiket  Furthermore,  the 

standard  had  to  be  a  non-proprietaiy  ’open'  standard.  The  selected  common  tool  interface  had  to 

be  capable  of  supporting  all  defence  software  engineering  needs.  Therefore,  some  improvements 

were  needed  in  PCTE.  notably  with  respect  to  security,  independence  of  operating  system,  and 

programming  language.  A  defence  project  was  set  up  by  the  Independent  Programme  Oroup 

Technical  Area  1 3  to  extend  PCTE  and  assess  the  result  , 

^  r* 

Within  the  lEPG  rA-13  programme  ten  European  countries  participate :  Belgium,  France, 

Germany,  Greece,  Italy,  the  Netherlands,  Spain,  Turkey,  and  the  United  Kingdom.  The  PCTE-f 
project  is  scheduled  to  complete  at  the  end  of  1992.  To  date  the  PCTE-»-  requirements  have  been 
established  and  the  PCTE-t-  standard  has  been  defined.  Within  the  programme  PCTE-f 
implementations  on  two  different  host  operating  systems  (UNIX,  VMS)  will  be  made  and  a  range 
of  tools  will  be  developed  or  ported  onto  PCTE-f . 

Since  ECMA  PCTE  fully  meets  the  PCTE-f  requirements,  there  now  is  an  international  public 
interface  standard,  supporting  defence  software  engineering  needs. 

2.23  PCTE  is  the  Open  Repository 

Speaker:  Mr  Robert  Cochran 

Mr  Cochran  (Catalyst  Software),  chairman  of  the  PCTE  Promotion  Group,  described  the  work  of 

the  PCTE  Interface  Management  Board  (PIMB)  as  well  as  that  of  the  PCTE  Promotion  Group 

(PPG).  The  PIMB  has  been  mainly  involved  in  building  the  PCTE  community,  the  PPG  is  ^ 

promoting  the  PCTE  take-up. 

In  1986,  at  the  end  of  the  PCTE  ESPRIT  project  32,  the  PIMB  was  created.  Its  main  role  has  beoi 
to  focus  and  coordinate  PCTE  activity,  thus  building  a  PCTE  community.  The  key  milestones 
reached  by  PIMB  are:  the  preparation  of  PCTE  1 .5,  the  sponsoring  of  ECMA  TC33.  the  creation 
of  the  PCTE  Newsletter,  and  the  establishment  of  the  PCTE  Promotion  Oroup.  The  PIMB  forms 
an  international  PCTE  fonun.  All  major  platfonn  vendors,  the  relevant  intematitmal  groups,  and 
representatives  finom  software  industiy  are  paiticipating  in  the  PIMB.  Furtheimore,  there  is  a 
rapidly  growing  interest  in  the  PIMB  from  tod  and  toolset  vendors.  Eariy  this  year  the  Terms  of 
Reference  of  the  PIMB  were  changed  radically:  the  PIMB  is  now  open  to  all  imerested 
organizations. 

The  PPG.  established  in  March  1990,  is  a  suuuling  committee  of  the  PIMB.  It  omidsts  of 
companies  commercially  committed  to  PCTE.  However,  the  does  not  promote  PCTE  I 

products;  it  promotes  the  PCTE  concepts.  The  nK3  monberi  jointly  pay  for  the  promditmal 
exposes.  In  addititm  to  this,  the  no  gets  8U{^it  fhmi  the  CEC. 


The  PPG  played  an  important  consultative  role  between  competitors,  thereby  creating  a  common 
maricet  understanding.  It  also  coordinated  attendance  at  exhibitions.  For  instance,  there  will  be  a 
PCTE  section  at  the  Toulouse  ctmference  in  December  this  year.  Furthermore,  the  PPG  is 
planning  the  institution  of  a  North  American  PCTE  Group. 

Mr  Cochran  stressed  that  the  goal  of  PIMB  and  PPG  is  to  promote  PCTE  as  the  de-facto  standard 
in  dominant  use.  Worthy  of  A  chairman  of  a  promotional  group,  Mr  Cochran  ended  his  talk  with 
some  slogans; 

PCTE  is  now  the  standard  Open  Repository. 

PCTE  is  here, 

is  in  use, 

is  endorsed, 

is  available, 

is  controlled. 

We  might  add  PCTE  is  here  to  stay. 

2.2.4  PCTE  and  CEC 

Speaker:  Mr  David  Talbot 

Since  the  CEC  is  a  long  temi  investor  in  PCTE,  Mr  Talbot  gave  an  investor's  viewpoint  of  PCTE. 
Mr  Talbot  estimated  that  to  date  more  than  $100  million  was  invested  in  PCTE  by  the  CEC,  the 
commercial  partners  and  the  military.  Mr  Talbot  first  sketched  the  background  motivations  for  the 
CEC  to  embark  on  the  PCTE  related  projects,  then  gave  the  current  position.  He  concluded  his 
talk  by  identifying  some  future  needs. 

According  to  Mr  Talbot,  the  background  motivations  of  the  CEC  for  starting  the  PCTE  project  are 
a  mix  of  facts  and  beliefs.  It  is  a  fact  that  software  becomes  the  dominant  cost  and  major  part  of 
the  added  value  of  computer  systems.  So,  there  is  a  common  belief  that  technology  support  for 
life  cycle  of  software  intensive  systems  is  critical.  There  is,  however,  no  quantified  result  to 
support  this  belief.  To  provide  full  life  cycle  support,  individual  CASE  tools  are  not  enough;  they 
need  to  be  integrated.  However,  the  CASE  methodsAools  market  is  still  relatively  small  and 
immature.  Therefore,  it  is  believed  th^  an  'integration  framework*  is  needed,  forming  a  basis  for 
improving  market  for  both  users  and  suppliers.  Such  a  framework  reduces  the  risk  and  investment 
for  vendors  and  provides  the  users  with  a  better  choice. 

To  fill  this  need  for  an  integrttion  framework,  the  CEC  initiated  several  tedinology  projects 
within  Esprit  Not  only  projects  supporting  the  development  of  a  pre-normative  standard  for  an 
open,  ponaUe  common  tool  environment,  but  also  prototype  projects  and  validation  experiments 
were  set  up.  Examples  of  these  ESPRIT  projecu  are  PCTE  (the  'base  project'),  PACT  ('tools 
projea')  and  ATMOSPHERE  ('systems  project').  To  support  the  open  and  public  evolution  of  the 
standard  the  PIMB  was  established. 
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Mr  Talbot  concluded  his  talk  by  identifying  future  needs.  His  conclusion  was  that  technology 
issues  are  currently  'second  order'.  N(Mi-technology  issues  are  of  major  importance.  Some  of  these 
issues  are: 

confidence  in  supply, 
back-up  capabilities, 
choice  of  implementation,  and 
easy  of  buying. 

2  J  Industrial  PCTE  Strategy 

2  J.l  Digital's  PCTE  sti  ategy 

Speaker:  Mr  Luciano  Vernocchi 

Mr  Verrxrcchi,  Digital  Equipment  Co.,  expressed  Digital's  commitment  to  standards  in  general 
and  to  PCTE  in  panicular.  He  sketched  the  COHESION  strategy  and  the  advantages  obtained  by 
incorporating  PCTE  within  the  COHESION  environment. 

Digital  is  strongly  committed  to  standards.  Existing  standards  are  accommodated  in  solutions  for 
customers'  business  problems  where  appropriate.  These  standards  are  adopted  while  protecting 
customers'  investment.  Digital  also  contributes  to  the  definition  of  new  standards  and  to  the 
evolution  and  convergence  of  existing  ones. 

In  accordance  with  their  commitment  to  standards.  Digital  contributed  to  ECMA-PCTE 
standardization  and  contracted  Emeraude  to  port  PCTTE  VI 2  to  Digital's  RISC  systems.  In  1988 
an  internal  research  project  was  started  to  demonstrate  that  PCTE  and  ATIS  can  be  merged  into  a 
single  implementation  supporting  both  interfaces.  Furthermore,  a  technical  architecture  was 
identified  which  enables  the  inclusion  of  PCTE  in  Digital's  COHESION  environment. 

COHESION  supports  application  development  and  deployment  for  multi-vendor,  integrated  and 
distributed  systems.  COHESION  is  designed  to  accommodate,  as  key  components,  new  relevant 
CASE  standards  such  as  PCTE  and  ATIS.  It  has  a  'plugable',  evolvable  and  flexible  architecture 
based  on  three  levels  of  integration:  presentation,  control  and  data.  Presentation  integration, 
giving  a  common  look  and  feel  tailored  to  CASE  work,  is  provided  using  Motif  (OSF). 

Control  integration  is  provided  by  the  use  of  the  Application  Control  Ardiitecture  Services 
(ACAS).  ACAS  are  proposed  by  the  Object  Management  Group.  They  provide  facilities  to  locate, 
lauiKh  and  connect  aiqrlications  in  a  distributed,  heterogeneous  environment  Object-oriented 
technology  is  used  to  register  aj^lications  and  their  services. 

Data  integration  is  obtained  by  ths  use  of  Data  Servers,  whidi  are  i^lications  registered  in 
ACAS.  These  servers  provide  a  single,  uniform  interface  for  tools  to  access  differem  repositories. 
They  provide  services  for  management  of  data,  versons,  and  configurations.  Curr»itly  targeted 
repositories  are  CDD/Repository  (ATIS)  and  PCTE. 
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Integration  of  PCTE  within  the  COHESION  enviroiunent  as  a  repositoiy,  enables  COHESION 
tools  to  access  PCTE  OMS  services  through  a  Data  Server  (or  a  Repository  Server).  The  PCTTE 
tools  integrate  with  ACAS  to  interoperate  with  'foreign*  COHESION  tools  and  other  PCTE  tools. 
Furthermore,  PCTE  tools  can  directly  access  OMS  services. 

Digital's  policy  to  integrate  PCTE  within  COHESION  offers  several  strategic  advantages: 
it  provides  distributed  and  flexible  control  integration  services  to  PCTE  based  on  the  OMG 
standard: 

it  provides  Multi*Repository,  Multi*Framework  portability  that  increases  capabilities  for 
Digital's  customers; 

it  enables  a  consistent  Software  Developmertt  Environment  for  PCTE  and  non-PCTE  based 
frameworks: 

it  facilitates  migration  from  existing  distributed  SEE  to  PCTE  distributed  SEE;  and 
it  supports  framework  convergence  acdvides  that  enhance  overall  hmcUonality  and 
minimize  associated  business  risks  for  tool  vendors  and  cu,stomers. 

2.3  J  Hewlett  Packard's  PCTE  plans 

Speaker:  Mr  George  Tatge 

HP  is  involved  in  two  CASE  businesses:  frameworks  and  environments.  It  delivers  the  SoftBench 
framework  and  licenses  its  technology  to  others,  and  delivers  C  and  C-m-  software  engineering 
environments  built  on  SoftBench. 

HP  endorses  the  use  of  ECMA  PCTE  as  the  open  repository  standard  for  CASE  frameworks.  The 
Data  and  Control  Integration  components  of  the  ECMA/NIST  Reference  Model  will  be  PCTE  and 
SoftBench.  HP  plans  to  implement  the  Conuxrl  Integration  standard  on  PCTE.  To  idendfy  the 
requirements  for  this  implementaUon  mrtjor  customers  and  vendors  will  be  consulted.  Projects  for 
this  development  are  now  being  staffed  at  Fort  Collins,  a  product  division,  and  Bristol.  HP  will 
continue  to  work  with  major  customers  and  vendors  to  standardize  CASE  frameworks. 

2  Ji  J  Industrial  PCTE  policy 

Speaker:  Mr  Phil  Thoniley 

Mr  Thomley,  British  Aero^ce  (Military  Aircraft)  Ud,  sketched  the  experience  gathered  in 
procuring  the  EuroFighter  IPSE.  Based  on  this  experience  the  AIMS  project  was  started.  He 
concluded  with  the  Aerospace  Requirements  for  an  IPSE. 

The  partners  in  the  EuroFighter  development  (Alenia,  BAe,  CASA  and  MBB)  agreed  that  an 
IF^E  was  required  to  develop  the  many  embedded  computer  systems  onboard  of  the  aircraft.  It 
took  about  flve  years  from  the  initial  discussion  on  requirements  for  this  IPSE  to  its  delivery.  To 
shorten  this  time  in  the  future  more  use  will  be  mtule  of  'off-the-shelf  products.  Therefore,  a 
competitive  sui^ly  of  environments  is  needed. 
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AIMS  is  an  Industrial  research  project.  Ihe  application  domain  is  embedded  computer  systems 
(ECS)  development  and  maintenance.  The  strategic  objectives  of  the  AIMS  project  are: 
to  improve  the  productivity  of  ECS  developmoit, 
to  stabilize  time  schedules  of  ECS  development, 

to  provide  for  the  effective  cooperation  of  the  European  Aerospace  Industry,  and 
to  improve  distinctly  ECS  quality. 

The  AIMS  project  consists  of  two  phases:  a  definition  phase  and  a  demonstration  {diase.  In  the 
first  i^iase  an  ECS  development  model,  the  probl«»  identification  and  analysis,  and  an  evaluation 
approach  were  produced.  In  the  second  frfiase  particular  solutions  will  be  evaluated  using  the 
agreed  evaluation  approach  in  demonstration  projects.  This  will  produce  evaluations  of  the 
solutions  as  well  as  of  the  evaluation  approach  itself.  Furthermore,  the  fundamental  features  of 
architectures  for  environments  will  be  defined.  The  work  wiU  be  undertaken  based  on  the 
following  strategy: 

1)  use  what  is  already  available; 

2)  influence  current  development  woiic; 

3)  carry  out  essential  work  where  necessary. 

In  accordance  with  this  strategy,  Mr  Thomley  participated  in  both  PQS  wcilcshops  and  in  the 
PCIS  expert  team  meeting.  Mr  Thomley  observed  that  PTI  programmes  arc  starting  to  address 
real  user  needs,  for  instance  evolution.  The  AIMS  project  will  put  forward  to  PCIS  a  detailed 
statements  of  requirements. 

Mr  Thomley  concluded  by  indicating  two  major  aerospace  requirements:  support  for  traceability 
and  long  term  support.  To  support  traceability  between  development  {riiascs,  fine  grain  data 
integration  is  needed.  Only  the  PTI  mechanism  should  be  used  for  this  integration.  Within  the 
Aerospace  industry  products  have  lifetimes  over  40  years.  So,  there  is  a  definite  need  for  long 
term  support  Therefore,  it  must  be  possible  to  update  the  enviroranent  technology  while  keeping 
full  access  to  the  data. 

23A  IBM  OPEN  ENTERPRISE  AD  Strategy  and  PCTE 

Speaker:  Mr  GermaiB  Sagols 

Mr  Sagols  of  IBM  outlined  OPEN  ENTERPRISE  Ai^lication  Development  and  its  relation  to 
PCTE.  IBM  supports  the  standardization  efforts  for  open  systems  in  general  and  PCTE  in 
particular.  Mr  Sagols  illustrated  IBM's  commitment  to  open  systems  with  two  quotations.  The 
second  quotation  explicitly  mentitmsd  PCTTE : "...  extensibility  to  accept  open  enteiprise  industry 
standards  as  they  emerge,  in  particular  ECMA  PCTE..."  (Open  Enterprise  AD  Aimouncement  of 
SeiHember  11th  1991). 

Within  OPEN  ENTERPRISE  Application  Develcpnent  two  types  of  {gatfoims  can  be 
distinguished:  IBM  AD/Cycle  and  IBM  AIX/CASE.  IBM  AD/Cycle  is  used  on  an  enterprise  level 
for  ai^lication  areas  like  fiitance,  inairance,  transportatitm,  public  sector  and  MIS  shops. 
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Standards  for  these  platforms  are  IBM  SAA.  IBM  API,  and  IBM  CPI.  IBM  AIX/CASE  platforms 
are  used  on  a  departmental  level  for  ^plication  areas  like  aerospace,  engineering,  military,  and 
telecom.  Standards  for  these  platforms  are:  Unix  System  V.2,  Unix  BSD  4.3,  OSF/Motif,  POSIX 
IEEE  1003.1,  and  ECMA  PCTE 149.  The  reference  model  for  AIXATASE  is  based  on  the  ECMA 
CASE  Reference  Model. 

Both  PCTE  and  AD/Cycle  are  responses  to  customer  demands  for  data  integration  v/orkbenches. 
In  1991  one  PCTE  workbench,  EAST,  became  available  on  the  RISC  System/6000.  Other 
workbenches,  CONCERTO  and  ENTERPRISE  II,  will  become  available  in  1992.  These 
workbenches,  offering  data  integration,  are  based  on  Emeraude's  V12  PCTE  implementation. 

Tool  data  integration  has  several  benefits.  Since  the  data  is  unique,  it  offers  high  reliability. 
Responses  to  change  are  easy,  since  it  provides  full  traceability.  It  is  easy  to  reuse  components, 
thereby  increasing  productivity.  The  mix  of  product  and  process  data  enables  to  achieve  a  high 
quality. 


2.4  The  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS)  and 

PCTE 

Speaker:  Dr  John  Kramer 

Mr  Kramer,  DARPA/SISTO  gave  an  overview  of  the  context  and  status  of  the  STARS  program. 
After  that,  he  discussed  the  relationship  between  this  program  and  PCTE,  He  concluded  by 
inviting  patties  to  participate  in  the  STARS  program. 

The  STARS  program  is  pan  of  the  DARPA  software  plan.  The  mission  of  DARPA  is  to  create  a 
breakthrough  in  the  technology  for  DoD  missions.  Within  the  DARPA  program  there  is  a  major, 
increasing  emphasis  on  information  technology.  The  DARPA  software  plan  is  organized  around 
the  strategic  themes  megaprogramming  and  infrasuveture/maturity  model.  This  plan  is  developed 
in  concen  with  wider  DoD  plans,  like  the  DoD  Software  Master  Plan  and  the  DoD  Software 
Tectuiology  Plan.  The  mission  of  the  STARS  program  is  to  meet  the  charter  goals  of  reducing 
DoD  software  costs  and  increasing  quality.  Ftirthermore,  it  has  to  accelerate  the  shift  to  a 
process'driven  paradigm  within  the  DoD  software-intensive  system  development  and 
maintenance  community.  The  paradigm  shift  diould  sui^rt  collaborative  development  across 
geographically  dispersed  project  teams. 

Influenced  by  the  mission  and  reuse  objectives,  domain  assets  are  developed.  These  a»ets  are 
process  definitions,  domain  architectures  and  components.  By  tailoring  the  domain  assets  to  a 
particular  af^lication,  an  t^lication  adapted  software  engineering  envirorunent  (SEE)  is 
developed.  Such  mt  environment  contains  development  tools,  life-cycle  process  and  an 

asset  library.  The  SEE  objectives  of  the  STARS  program  are: 

to  demonstrate  the  benefits  of  a  framewoik-based  approach  to  instantiation  of  software 
engineering  environments  (SEEs); 
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to  reduse  adoption  risks  inherent  in  integrating  and  utilizing  new  technologies; 
to  ensure  that  the  basic  infrastructure  is  available  to  support 
process  management  and  control, 
reuse  libraries  and  sui^rt  mechanisms,  and 
tool  Interoperability  and  integration. 

Within  STARS  standards  are  selected  using  the  following  criteria  (in  priority  order): 

1 .  relation  to  problem  domain, 

2.  coverage  of  requirements  (engineering), 

3.  STARS  prime  concurrence  (maiketplace). 

4.  availability  of  products  within  STARS  timeframe. 

5.  maturity  -  standards  spectrum  of  international,  national,  de-facto  (stability). 

STARS  develops  no  standards,  but  acts  as  a  neutral  territory  for  tool  vendors,  frameworic 
providers,  and  standard  groups.  STARS  role  is  to  focus  attention  and  to  disseminate  information. 
Within  STARS  several  standards  are  agreed  upon  by  all  primes,  e.g.  POSIX,  X-Window^Motif. 
However,  STARS  has  not  selected  a  standard  for  OMS.  The  two  main  candidates,  CIS  ATIS  and 
ECMA  PCTE,  are  relatively  immature.  Both  are  primarily  test  vehicles  for  OMS  technology. 
Moreover,  the  operational  experience  with  either  is  limited.  As  on-going  activity  within  STARS 
use  is  made  of  a  framework-based  SEE  test-bed  u>  explore  interoperability  and  evaluate 
integration  issues.  Furthermore,  'right'  versus  'wrtmg'  standards  profile  are  identified.  The 
commercial  counterparts  within  STARS  are  actively  involved  in  this.  STARS  provides  a  neutral 
ground  for  industry-wide  profile  discussions.  The  STARS  profile  will  be  used  on  three  instances. 
These  instanceswill  be  performed  by  Boeing,  IBM  (FDS),  and  Unisys  Defense  Systems,  Inc. 

Boeing  established  an  alliance  with  DEC  to  have  eariy  access  to  new  products,  to  feed  'real' 
requirements  to  DEC,  and  to  have  long-term  product  support.  Furthermore,  Boeing  wanted  to 
utilize  DEC  Cohesion  and  open  interface  standards.  Boeing  will  build  a  SEE  in  order  to 
demonstrate  data  integration,  a  process-controlled  environment,  reuse  and  reuse  tools  integral  to 
the  process,  and  integration  of  systems  and  software  engineering.  Boeing  will  incrementally 
incoiporate  process  and  reuse  technologies. 

IBM  Federal  Systems  Development  will  utilize  commercial  oft'-the-shelf  products,  since  many 
components  are  now  availatde.  Their  SEE  will  stay  compliant  with  open  systems  standards  like 
POSIX,  X/Motif  and  PCTE.  It  will  be  configured  as  solution  sets  capable  of  supporting  'unique' 
DoD  requirements. 

Unisys  Defense  Systems,  Inc,  wiU  also  use  conunercial  off-the-shelf  products,  namely  Emereude 
PCTE,  Enterprise  II,  and  Software  through  jrictures.  It  will  evolve  artd  integrate  Unisys  tools  Oike 
READS.  RLF  Reuse  Library)  on  open  frameworks.  Other  capabilities  will  be  integrated,  e.g. 
Arcadia  metrics  collection  and  process  mechanisms. 
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2.5  Panel:  "Technology  Push,  Smart  Buyers,  and  Market  Pull. 

The  Forces  Accelerating  PCTE7" 

Chalrmin:  Mr  v«n  Hock 

Mr  van  Hoek,  Director  Defence  Research  and  Development,  Netherlands  Ministry  of  Defence, 
first  inuoduced  the  panel  members: 

Mr  Ian  G.  Campbell,  Emeraude 
Mr  Myer  W.  Morron,  ECMA  TC33 
Mr  John  F.  Kramer,  DARPA 
Mr  Geimain  Sagols,  IBM 
Mr  David  Talbot,  CEC 
Mr  George  Tatge,  HP 
Mr  Luciano  Vemocchi,  Digital 

During  the  introduction  of  the  panel  members  by  Mr  van  Hoek,  it  was  revealed  that  a  commercial 
PCTE  implementation  might  become  available  from  India.  Heuristix  Ltd  based  the 
implementation  of  their  repository  on  the  ECMA  PCTE  specification.  They  will  probably  bring 
out  a  full  implementation  of  ECMA  PCTE.  Currently  there  are  two  commercial  PCTE 
implementations  available,  one  from  Emeraude,  which  is  already  sometime  on  the  market,  and 
one  from  Verilog.  After  his  introduction  Mr  van  Hoek  invited  the  conference  participants  to  ask 
questions. 

Q.  J.  Solomond,  AJPO:  Europe  invested  500  manyears  in  PCTE,  was  this  totally  from  the  CEC? 

Is  some  of  the  enthusiasm  for  PCTE  not  based  on  the  invesunent  to  date? 

A.  Morron:  It  is  difficult  to  give  an  accurate  estimate,  since  there  were  many  peripheral 
projects.  Anyway,  the  investment  must  be  500  to  1000  manyears,  including  industrial 
investment.  This  amounts  over  $100  M  ($50  M  for  CEC).  Enthusiasm  for  PCTE  is  not  based 
on  money  spent,  but  on  belief  in  PCTE. 

A.  Campbell:  This  amount  does  not  include  all  investments,  e.g.  the  investment  in  French 
projects.  I  cannot  be  enthusiastic  about  just  investing  money.  However,  it  was  not  at  all  a 
bad  idea  to  invest  in  PCTE. 

Q.  Unknown:  Is  STARS  a  defence-related  mixture  of  civil  and  defence  spending?  Over  a  period 
of  time  defence  spending  will  decrease  more  and  more.  The  key  issue  is  to  use  leverage  to 
make  txire  that  developments  meet  your  own  wishes. 

A.  Knuner  We  must  realize  that  defence  will  be  just  a  small  amount  of  the  market  place. 
STARS  is  building  on  COTS.  The  DoD  should  not  spend  a  lot  of  money  on  technology  .  If 
the  STARS  demonstrations  fail,  the  suf^liers  will  have  failed.  They  have  let  me  prove  that 
they  cut  not  do  the  job. 

A.  Tatge:  It  does  not  make  much  dinerence  where  the  money  is  from.  A  good  sign  for  us  is  that 
companies  are  takii^  advantage  of  things  put  into  the  public  dom^n.  Also,  the  US 
involvemoit  is  encouraging. 


A.  Vemocchi:  It  is  difficult  for  us  to  promote  a  European  standard  in  the  US.  The  basic  support 
for  this  came  horn  the  US  defence  industry.  So,  they  took  the  lead  in  these  developments. 
Europe  was  good  in  setting  up  and  defining  PCTE.  The  US  is  trying  to  work  out  a 
convergence. 

A.  Sagols;  The  frontier  between  defence  and  civil  applications  is  disai^jearing. 

Q.  N.  Wybolt,  Cadre:  How  can  tool  providers  be  blamed,  if  they  do  iK>t  own  the  enabling 
technology? 

A.  Kramen  Take  it  as  a  challenge.  If  I  have  to  spend  90%  of  my  money  on  integrating  Cadre, 
then  two  companies  have  faded:  Cadre  and  the  platform  provider. 


Q.  T.  Oren,  University  of  Ottawa:  Did  PCTE  carry  Open  Systems  to  higher  levels? 

A.  Morron:  First  there  used  to  be  a  lot  of  discussion  on  hardware  level  standardization,  then  on 
operating  systems  (Unix,  Posix).  Manufacturing  companies  spent  most  of  their  money  on 
operating  systems.  Currently,  there  is  some  agreement  on  Unix/OSI.  It  is  becoming  part  of 
tlie  plumbing.  (PCTE  originated  as  a  Unix  extensim  for  SEE.)  I  would  like  to  see  PTIs  to 
become  pan  of  the  plumbing  too.  It  is  time  to  move  to  higher  levels:  standard  schema 
libraries,  interface  formats,  etc. 

Q.  N.  Wybolt,  Cadre:  Is  there  any  work  perfonned  on  migration  guides  for  tool  builders  by  the 
platform  suppliers? 

A.  Campbell:  Several  environment  suppliers  are  keen  to  tell  tool  suppliers  how  they  can 
integrate  their  tools.  Most  oner  tools  supponing  an  initial  loose  integration,  which  can  be 
tightened  later  on.  You  should  make  the  experience  gained  available  to  people  interested. 
Furthermore,  you  should  get  advice  from  the  environment  supplier  how  to  cater  for 
evolution. 

A.  Tatge:  Look  at  how  we  developed  Sof£ench. 

Q.  N.  Wybolt,  Cadre:  Broadcast  integration  like  in  SoftBench  is  easy.  We  like  to  change  the 
schemas.  Integration  guides  will  provide  support  for  assessing  migration  costs.  Will 
integration  guides  become  available? 

A.  Vemocchi:  ¥PO  also  recognizes  the  need  for  integration  guides.  Today  you  can  micapsulate 
a  tool,  but  this  doesn't  solve  integration  yet 

A.  Sagols:  This  is  the  domain  of  the  tool  builder,  not  of  the  end  user.  PCTE  technology  is 
difficult  to  understand.  For  integration  the  next  step  will  be  a  standardized  data  model. 

Q.  E.  Andrd,  SEMA:  Will  platform  suiqiliers  provide  proprietary  imidementations  for  free,  like 
they  do  with  XI 1? 

A.  Campbell:  It  is  a  mirtake  that  you  get  such  an  iton  for  free:  it  is  bundled  as  part  of  die 
operating  system.  When  PCTE  is  part  of  the  plumbing,  it  should  be  bundled. 
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Q.  I.  ITKMnas;  What  are  major  impediments  for 

-  widespread  use; 

-  acceptance  and  success  on  a  world>wide  basis; 

•  a  commercially  successful  business? 

A.  Gladman:  We  are  at  the  end  of  the  beginning.  The  big  question  is  now  whether  the  standard 
will  become  a  true  multi<vendor  standard.  So.  the  key  issue  is  investment  form  industry. 
However,  we  have  to  consider  that  going  from  concqrt  to  reality  takes  a  decade. 

A.  Morron:  My  company.  BNR  is  a  potential  user.  ECMA  PCTE  meets  long  term  requirements 
for  a  repository.  However,  it  is  absolutely  important  to  have  different  implementations, 
probably  for  different  kinds  of  application  domains.  The  neutral  aspects  of  the  staiKlards  can 
be  implemented  diH'erently. 

A.  Roach,  Digital:  This  question  on  impediments  was  asked  during  a  basic  customer  research 
earned  out  by  us.  The  biggest  impediment  appeared  to  be  that  we  as  vendors/standardization 
bodies  have  failed  to  show  customers  what  return  on  investment  there  will  be.  Technological 
impediments  were  not  mentioned  at  all. 

A.  Campbell:  Most  buyers  are  hesitant  We  are  also  moving  into  MIS  market  and  the 

telecommunications  market.  I  am  optimistic:  within  five  years  we  do  not  need  to  discuss  this 
issue  anymore. 

Q.  D.  Longden,  UK  MoD:  We  have  implementations  of  PCTE  1 .5,  not  of  ECMA  PCTE.  When 
will  EC^A  PCTE  implementations  become  available? 

A.  Campbell :  We  have  plans  to  produce  ECMA  PCTE  implementations. 

A.  Venxxxhi:  Using  different  names  caused  a  major  confusion  in  the  market.  This  was  wrong 
from  a  marketing  point  of  view.  Most  manufacturers  have  intentions  to  produce  PCTE. 

Q.  H.  Davis,  ICL:  There  is  a  need  to  get  the  tool  suppliers  together  and  talk  how  to  handle  this 
technology.  In  North  America  there  is  a  initiative  for  a  PCTE  users  group.  Is  there  also 
something  going  on  in  Europe? 

A.  Cochran:  The  PIMB  is  changing  into  such  a  group.  Maybe  later  on  there  will  be  a  separate 
users  group.  At  the  Esprit  Technical  week  this  point  was  discussed.  The  conclusion  was  that 
forming  such  a  group  is  not  necessary  at  this  time. 

Q.  BJP.  Bhat,  Heurisdx:  As  a  repository  supplier  we  are  interested  in  the  certification  of  our 
products.  Are  there  any  medianisms  for  this? 

A.  Talbot:  Currently  there  are  no  certific^on  mechanisms  for  PCTE.  But  in  the  EEC  (as  well 
as  in  the  US)  mechanisms  for  certification  are  being  developed.  As  soon  as  the  market  place 
asks  for  them,  they  will  become  available. 

Q.  Demiame,  CRIN:  The  number  of  tool  interfaces  we  need  is  small  (rme  ortwo).  The  number 
of  interface  implementations  will  also  be  small  (two  digits,  about  twenty).  However,  the 
number  of  environments  will  be  large  (three  digits).  Success  of  PCTTE  will  be  erqnessed  in 
the  availability  of  envirorunents.  Outside  PCJTE  a  lot  of  technological  issues  have  to  be 
solved,  like  integration  and  common  data  schemas. 
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A.  Oladman:  It  will  take  about  five  years  to  get  PCTE  finnly  embedded. 

A.  Talbot;  The  issue  is  not  whether  PCTE  is  successful,  but  whether  software  engineering  (SE) 
is. 

Do  people  take  software  serious 
Do  people  take  software  production  serious 
Do  people  think  SE  contributes  to  software  production 
Do  people  believe  PCTE  contributes  to  SE 

Again,  the  important  issue  is  to  get  evidence  for  return  on  investment.  We  should  do  this 
before  spending  mote  money  on  tedinology. 

Mr  van  Hoek  rounded  off  the  discussion  by  stating  that  there  is  no  doubt  whether  PCTE  exists. 
However,  that  is  no  reason  to  sit  back  and  be  satisfied. 

2.6  A  Management  Introduction  to  PCTE 

Speaker:  Mr  Ian  CampbeU 

The  Decision-Makers'  Day  was  concluded  by  a  management  introduction  to  PCTE  given  by  Mr 
Campbell  of  Emeraude.  This  gave  him  the  opportunity  to  use  the  promotional  slides  produced  by 
the  PPG. 

According  to  Mr  Campbell  software  plays  a  cracial  role  in  business  success.  It  is  used,  for 
instance,  for  office  automation  and  in  communication  systems.  Nowadays,  the  profitability  of 
business  relies  on  software  capabilities.  Therefore,  the  quality  of  software  may  become  (and  is 
often)  a  limiting  factor  in  economic  growth.  It  affects  operations  such  as  manufacturing  and 
decision  making.  For  this  reason  software  engineering  should  not  be  treated  as  just  a  technique:  it 
is  a  corporate  resource. 

However,  software  production  cannot  match  the  increasing  needs.  This  is  illustrated  by  the  fact 
that  currently  the  large  majority  of  software  development  companies  still  finds  itself  at  the  lowest 
level  of  the  software  process  maturity  model.  This  maturity  model,  developed  at  the  Software 
Engineering  Institute  of  the  Carnegie  Mellon  University,  distinguishes  five  levels  of  process 
maturity:  initial  'handcrafted',  repeatable,  defined,  managed  and  ftiUy  engineered.  A  key  challenge 
is  associated  with  each  level.  The  key  challenge  of  level  four,  a  managed  process,  is  to  get 
ai^ropriate  CASE  tools  integrated  in  a  Software  Engineering  Environment  (SEE). 

A  basic  SEE  consists  of  many  tools,  which  are  not  integrated.  By  sharing  data,  the  tools  can  be 
integrated  into  a  repository  based  SEE.  A  well-known  model  for  SEEs  is  the  Open  S^  Reference 
Model  of  NIST/ECMA.  In  this  model  the  services  needed  for  the  integration  of  tools  in  a  SEB  are 
idoitifled.  The  services  are  for:  data  rqxisitory,  data  integratiim,  task  management,  user  interface, 
and  message  server.  These  services  must  rely  cm  Open  Standards. 
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In  the  area  of  software  engineering  there  are  several  open  standards,  for  instance,  for  portable 
operating  systems  (POSIX).  portable  languages  (ANSI:  Ada.  C.  C^obol.  Fortran),  portable  user 
interfaces  (X> Windows.  OSF/MotiO>  However,  the  keystone  of  software  engineering  success  is 
an  Open  Repository  based  on  open  public  standards.  The  only  available  portable  open  repository 
today  is  PCTTE.  the  Portable  Conunon  Tool  Envlronmertt.  It  is  a  public  standard  artd  provides  a 
solution  for  Open  Systems. 

The  global  characteristics  of  PCTE.  the  Open  Repository,  are: 
data  distribution  across  a  network  (real  distribution), 
data  base  consistency  and  integrity  control  (transactions), 
security  (access  control,  concurrency  synchronization),  and 
modularity,  on-line  modification  of  data  models. 

All  these  characteristics  provide  Quality  Support  for  the  Software  Development  Process. 


3 


APPUCATION-BUILDERS*  DAY,  THURSDAY  26  SEPTEMBER  1991 


On  the  Af^lication  Builders'  Day,  the  second  day  of  the  conference,  several  environment  builders 
described  how  they  extended  the  ci^Mbilities  of  PCTE  to  satisfy  several  impoitant  user  needs,  e.g. 
customizibllity  and  traceability.  They  also  indicated  the  lessons  learned  on  the  usaUlity  of  PCTE. 
Furthermore,  there  were  some  more  geiwral  talks  on  CDIF,  PCTE  training,  and  comparing  current 
repository  offerings. 

3.1  To  build  an  Environment  on  top  of  PCTE 
Speaker:  Prof.  Dernlame 

Prof.  Demiame  of  the  University  of  Nancy  described  how  the  users'  need  to  tailor  software 
engineering  environments  is  satisfied  by  ALF  (Accueil  de  Logiciel  Futur  -  see  [5]  for  more  on 
ALF).  In  the  ALF  Esprit  I  project  an  environment  framewoilc  has  been  built  on  top  of  Emeraude's 
PCTE  implementation.  This  framework  can  be  customized  using  a  MASP  (Models  for  Assisted 
Software  Processes)  resulting  in  an  ALF-based  IPSE. 

The  aim  of  ALF  is  to  provide  customizable  environments  which  allow  people  to  define  their  jobs 
in  terms  of: 

the  tools  they  will  use; 

the  order  that  they  wiU  do  things; 

the  permissions  and  degrees  of  freedom  they  will  have  to  work  in; 
the  schedules  they  must  keep  to. 

Within  ALF,  this  goal  is  achieved  by  providing  process  modeling  capabilities. 

A  software  process  is  a  set  of  engineering  activities  for  transforming  users'  requirements  into  a 
running  software  system  and  for  maintaining  it.  This  process  encompasses  both  technical  and 
managerial  concerns.  Within  ALF  the  MASP  concept  provides  a  formalism  to  describe  various 
software  process  models  in  a  uniform  way.  By  instantiating  this  MASP,  using  an  Instantiated 
MASP  (IMASP),  a  project-specific  process  description  is  derived.  Execution  of  an  IMASP  by 
ALF  results  in  an  Assisted  Software  Process  (ASP). 

In  the  ALF  project,  an  ALF  system  and  a  Framework  for  ALF-based  IPSEs  are  built.  The  ALF 
system  supports  the  modelling  of  the  software  process  resulting  in  the  construction  of  a  MASP. 

By  plugging  the  MASP  into  the  framework,  an  ALF-based  IPSE  is  obtained. 

3.2  Meeting  User  Requirements  for  Control  In  a  Large  Scale  IPSE 

Speaker:  Mr  Martia  Kirby 

Mr  Kirby  of  SD-Scictm  demonstrated  how  the  main  user  requirements  (authority,  stability,  and 
reliability)  for  the  EuroFighter  Aircraft  (EFA)  IPSE  could  easily  be  met  by  PCTE. 
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In  the  EFA  IPSE  there  are  four  different  authority  entities:  users,  domains,  tasks,  and  commands. 
The  users  can  be  modelled  as  PCTE  user  objects,  domain  and  tasks  as  user  groiq)s,  and 
commands  as  program  groups.  The  stability  requirements  can  be  met  by  placing  stabilizing  links 
to  make  public  data  immutable.  Navigation  restrictions  give  a  stable  domain  name  ^ce. 
Reference  links  protect  data  in  use  from  deletion.  To  achieve  reliability,  transactions  can  be  used 
for  atomic  updates.  Program  groups  and  usage  modes  can  realize  non-falsifiable  accolades. 

According  to  Mr  Kirby,  the  management  conditions  of  the  EFA  IPSE  m^  directly  to  PCTE 
facilities.  Use  of  these  facilities  makes  the  tools  independent  of  management  conditions.  So  it  is 
not  necessary  that  tools  call  other  tools  or  interfere  with  life-cycle  tools.  The  knowledge  about  the 
management  method  does  not  have  to  be  incorporated  in  the  tools. 

A  participant  at  the  cottference  sununarized  the  keypoint  of  Mr  Kirby's  case  as  follows:  major 
user  requirements  can  easily  be  met  by  tool  providers  by  building  tools  on  top  of  PCTE;  therefore, 
procurement  of  an  IPSE  will  not  take  as  long  (live  years)  as  it  took  to  procure  the  Eurofighter 
IPSE. 


3.3  Building  an  IPSE  on  top  of  PCTE 

Speaker:  Mr  Bourgulgnon 


Mr  Bourgulgnon  of  SFGL  described  the  lessons  learned  in  the  Eureka  EAST  project.  The  EAST 
project  aims  at  implementing  and  marketing  a  Software  Engineering  Environment  that  is 
adaptable  to  the  users'  needs  and  is  easy  to  use.  EAST  is  based  on  Emeraude  V12  and  fully 
exploits  the  PCTE  functionalities. 

Based  on  three  years  of  industrial  PCTE  use,  Mr  Bouigiiignon  concludes  that  PCTE  can  be  used 
in  two  ways:  for  tool  integration  and  for  information  system  modelling.  Tool  integration  is  a 
means  to  master  the  complexity  of  developing  software  engineering  tools.  Infonnation  systems 
modelling  is  a  means  to  master  the  complexity  of  projects. 

Tool  integration  facilitates  the  optimizMion  of  development  costs.  Tools  can  be  easily  integrated 
in  an  Open  Environment  that  provides  data  evolution  and  tool  encapsulation.  Within  EAST  data 
evolution  is  supported  by  the  SDS  ami  Working  Schema  concepts  of  PCTE.  To  integntte  a  tiiird 
party  tool  into  EAST,  it  is  encapsulated.  This  encapsulaticm  provides  an  interface  with  the  PCTE 
OMS  for  data  integration,  and  an  interface  with  the  EAST  User  Interface  Managmnent  System  for 
presentation  integratitm.  Presentation  integration  is  (mly  complete  for  btu^  tools. 

To  master  the  complexity  of  projects,  the  develq;)ment  {Hocess  must  be  modelled.  PCIE  allows  to 
model  data  manipulated  by  any  actor  and  to  model  any  (Mocess.  In  this  way.  an  infoimatitm 
system  dedicated  to  software  development  can  be  oonsinicted.  This  information  aystmn  mpports 
8trat''gic.  managmnem  and  t^ratitmal  activities.  By  onichlng  the  infoimatkm,  die  increase  in 
complexity  may  be  mastered.  This  enrichmeitt  is  enabled  by  the  evolutivity  of  the  PCTE  Dtta 
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Model.  To  enable  the  useis  to  enrich  their  own  information  system,  the  data  schemas  of  the  tools 
shall  be  published  and  some  shall  be  standardized. 

3.4  Object  Granularity  In  the  Concerto  Repository 

Sptakcr:  Mr  AndrS 

Mr  Andid  of  Serna  Group  addressed  the  problem  of  grain  size  in  SE  environments  and  the 
solutions  provided  in  the  Concerto  environment  He  argued  that  fine  grained  objects  arc  necessary 
to  support  traceability.  However,  using  fine  grained  objects  could  lead  to  peiformaitce 
degradation. 

Within  the  Concetto  environment  the  problem  of  grain  size  has  been  solved  by  providing  a 
generic  repository  interface.  This  generic  interface  is  built  on  top  of  each  specific  repository.  In 
this  way  a  clear  distinction  is  made  between  logical  organization  and  physical  implementation. 
The  way  a  specific  object  type  is  implemented  and  cached  is  left  to  the  experts  in  the 
corresponding  domain.  Efficiency  can  be  obtained  by  relying  on  the  structuring  concepts  for  that 
particular  type. 

According  to  Mr  Andrd,  the  Concetto  architectural  model  does  not  conflict  with  the  PCTE  Objea 
Management  System.  It  provides  progressive  integration  and  proposes  migration  paths.  However, 
the  PCTE  implementation  has  to  address  the  problem  of  grain  size. 

3J  The  CASE  Data  Interchange  Format  (CDIF)  Standards 

Speaker:  Mr  Mike  Imber 


Mr  Imber  of  LBMS  described  the  CASE  Data  Interchange  Fbrniat  (CDIF)  standards  and  their 
relation  to  PCTE.  The  objective  of  CDIF  is  to  facilitate  exchange  of  information  between  CASE 
tools.  This  is  achieved  by  providing  a  dngle  interchange  format  for  use  between  CASE  tools.  This 
requires  definition  of  the  meaning  (the  semantics)  of  information  transferred,  and  of  the  transfer 
format. 

To  define  the  semantics  and  the  forniat  of  information  transferred  a  four-layer  architecture  is 
used.  The  first  layer  of  this  architecture  is  the  Data  Layer,  consisting  of  the  instances  of  objects  in 
the  tool's  model.  The  second  layer  is  the  Model  Layer,  consisting  of  the  CDIF  Models,  the  actual 
informtuion,  transferred  between  tools.  The  diird  layer,  the  Meta-model  layer,  consists  of  CDIF 
models  for  CASE.  A  Meu-model  is  qdit  up  iiuo  two  models:  a  semarttic  modeL  defirdng  the 
semantic  aspects  of  models  transferred,  and  a  presenudon  model,  (tefbdng  the  graphical 
representation  of  models  transferred.  The  last  layer,  the  M^-meta-model  Layer,  gives  rules  for 
building  CDIF  Meta-models. 
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The  CDIF  standards  will  be  initially  used  to  define  models  for  tools  in  the  "U{^r-CASE"  area, 
since  this  area  is  best  undeistood  due  to  widespread  usage.  This  choice  will  enaUe  CDIF  to  be 
used  by  greatest  number  of  tools  with  initial  coverage. 

Users  benefit  fiom  CDIF  by  being  able  to  select  the  most  appropriate  tools  for  each  stage  of  the 
development  process.  It  enables  them  to  transfer  information  between  tools  without  having  to 
rekey  it  and  enables  them  to  avoid  tool  versioning  proUems.  In  this  way  the  investment  of  users 
in  CASE  tools  is  protected.  Vendors  benefit  horn  CDIF  by  being  able  to  satisfy  the  users'  request 
for  interfaces  in  a  generic  manner  with  a  single  interface,  thereby  avoiding  maintenance  and 
investment  problems  inherent  in  the  provision  of  multiple  interfaces. 

CDIF  can  be  used  for  the  interchange  of  information  between  PCTE  databases  or  between  a 
PCTE  database  and  another  environment  The  CDIF  standards  also  provide  a  means  to  define 
standard  SDSs  to  enable  tool  communication.  Using  the  CDEF  standards  for  PCTE  is  an 
assessment  of  the  modelling  capabilities  underlying  these  standards:  "Can  CDIF  express  the 
capabilities  of  PCTE,  like  distinct  SDSs,  shared  objects,  and  link  types?"  (See  [8]  for  further 
information  on  PCTE  and  CDIF). 

3.6  ToolBuider  and  the  Open  Repository 

Speaker:  Mr  Paul  Harris 

Mr  Harris  of  IPSYS  Software  He.  first  outlined  the  difterences  between  first  and  second 
generation  CASE.  Then  he  discussed  meta  CASE  tools.  He  concluded  with  a  discussion  of 
repositories. 

The  first  generation  of  CASE  tools  consisted  of  "simple",  single  purpose  tools.  These  tools  could 
not  be  configured  or  integrated.  They  were  mostly  built  to  provide  a  short  term  solution.  The 
second  generation  CASE  tools  consists  of  tailored,  configurable  life  cycle  tools.  They  support 
methods  which  are  suited  for  a  particular  organization.  These  tools  provide  a  strategic,  long-teim 
solution. 

Second  generation  CASE  tools  are  introduced  in  an  organization  using  a  tq^own  qtproach, 
consisting  of  three  stages.  In  the  flret  stage  the  software  process  and  quality  asniraiK^e  models  are 
identified,  resulting  in  a  description  of  the  organization's  own  method.  In  the  second  stage  the 
repository  strategy  is  defined  and  the  tools  needed  to  support  the  method  and  strategy  are 
identified.  It  is  likely  that  there  is  a  need  for  meta  CASE  tools.  In  the  last  stage  the  software 
process  and  quality  assurance  is  automated. 

II^YS'  ToolBuider  is  a  meu-CASE  tool,  a  CASE-tod  ^nerator.  Central  to  this  ToolBuider  is 
IPSYS'  repository  technology,  which  is  naturally  ERA  and  PCTE  compliant  To  solve  granularity 
problems  it  has  a  two-der  data  model:  the  first  tier  is  for  coarse  grdn  data,  die  secemd  der  for  fine 
grain  data. 
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3.7  Implementation  of  a  Complex  Software  Development  Environment  •  EPOS  in 

a  PCl'E-f  Environment 
Speaker:  Mr  Rau 


Mr  Rau  of  GPP  described  the  EPOS  (Engineering  and  Project  Management  Oriented 
Specification)  environment.  EPOS  is  an  IPSE  suppoiting  development  as  weli  as  reverse 
engineering.  It  is  a  proven  product  interfacing  with  many  other  tools  of  different  manufactureis. 
However,  it  has  a  dedicated  repository,  dedicated  user  interface,  and  is  dependent  on  the  data 
security/integrity  of  the  underiying  operating  system. 

Within  GPP  a  strategic  decision  has  been  taken  to  use  PCTE  in  order  to  improve  standardization 
and  user  acceptance.  The  PCTE  Object  Management  System  will  be  used  for  data  integration  and 
OSF/Motif  for  user  interface  integration.  Control  integration  will  partly  be  achieved  using  PCIE 
access  control  functions. 

According  to  Mr  Rau,  PCTE  offers  a  variety  of  promising  features  that  are  of  interest  to  software 
tool  manufactureis,  e.g.,  a  common  repository,  data  security  functions,  and  data  exchange 
mechanisms.  However,  the  question  of  semantical  data  exchange  between  tools  is  still  an  open 
issue. 

The  first  version  of  the  PCTE  port  of  EPOS  will  be  built  on  Emeraude's  PCTE+  prototype 
implementation.  The  release  to  customers  is  expected  at  the  end  of  1992.  Several  purchase 
options  have  already  been  placed. 

3.8  PCTE  Training  •  Experiences  of  UCW  Aberystwyth 

Speaker:  Dr  Mark  KatcUfTe 

Mr  Ratcliffe  of  the  University  College  of  Wales  at  Aberystwyth  described  the  contents  of  the 
PCTE  course  given  at  his  university.  The  emphasis  of  the  course  is  on  gaining  practical 
experience.  During  the  course  the  TIPSE  (Teaching  IPSE)  built  on  top  of  PCTE  is  used.  TIPSE 
provides  a  fully  integrated  environment  for  teauiing  software  engineering.  It  is  an  ideal  training 
environment  for  PCTE.  To  emphasize  the  benefits  PCTE  gives,  TIPSE  does  not  hide  PCTE  from 
its  user. 


3.9  The  HyperWeb  Project 

Speaktr:  Dr  Gtrard  Manai 


The  HyperWeb  technology,  described  by  Mr  Memmi  of  Bull,  is  based  on  die  observation  diat 
software  is  a  composite;  it  is  more  than  code,  more  than  text  Software  is  a  complex  "web”  of  all 
kinds  of  information.  This  information  can  be  efficiently  accessed  using  the  hypertext  cqiability 
of  HyperWeb  offered  by  qiecial  ediUng  tools. 


In  the  architecture  of  HyperWeb  three  layers  can  be  Identifled:  the  editing  tools,  the  HyperWeb 
server,  and  the  CMS  server  and  its  common  services.  The  editing  tools  make  up  the  user 
interface:  the  Outline  Web  Editor,  the  Link  Editor,  and  the  Node  Creator.  The  HyperWeb  server 
is  the  kernel  of  HyperWeb.  It  consists  of  three  parts:  a  scripting  language,  a  communication 
protocol,  and  an  interface  to  PCTE.  The  scripting  language  enables  a  user  to  customize  the 
HyperWeb  environment  Each  instance  of  the  HyperWeb  server  is  dedicated  to  one  user.  The 
OMS  server  on  the  other  hand  manages  the  data  for  all  users.  Configuration  management  and 
query  facilities  have  been  added  to  the  OMS  as  common  services.  Configuration  management  has 
been  built  using  the  Version  Management  Common  Service  (VMCS)  provided  by  Emeraude  V12. 

Based  on  the  HyperWeb  prototype  a  product  will  be  developed.  This  product  will  become 
available  at  the  beginning  of  1992.  At  the  Bull  site  in  Phoenix  HyperWeb  is  currently  used  to 
maintain  code.  The  intention  of  this  pilot  project  is  to  learn  to  efficiently  use  the  hypeitext 
technology  for  maintenance. 

3.10  Comparing  Current  Repository  Offerings  (PCTE,  IBM  RM,  IRDS) 

SpcMkcr:  Mr  Jean  B^ruM 

A  Study  comparing  PCTE  with  other  current  repository  offerings  was  reported  on  by  Mr  Bdrubd 
of  Orsand  Ltd.  The  initial  focus  of  this  study  carried  out  for  NIST,  was  the  comparison  of  ISO 
and  ANSI  IRDS.  However,  in  the  repori  it  will  be  made  clear  that  there  is  more  than  those  two: 
IBM  Repository  Manager  and  PCTE  have  also  been  included  in  the  study. 

In  the  study  the  data  concepts,  architectures  and  modelling  conventions  of  the  reviewed 
repositories  were  compared.  Other  aspects  of  repositories,  like  the  information  model  and  process 
modelling  convention,  have  been  left  out  Comparing  the  information  model,  for  instance,  is  not 
possible,  since  PCTE  does  not  include  a  definition  of  a  standard  information  model  unlike  IBM 
RM  and  IRDS. 

Several  ambiguities  and  confusions  were  identified  during  the  study.  When  comparing 
architectures,  confusion  is  caused  by  differences  in  the  description  of  the  conceptual,  logical  and 
physical  architecture.  All  studied  repositories  support  the  Entity-Relationship  Model  for  data 
modelling.  However,  it  is  not  clear  which  model  is  precisely  meant:  the  model  as  defined  by 
Chen,  the  model  based  on  the  Network  Data  Model,  the  model  based  cm  the  relational  model,  or 
an  exumded  model.  Moreover,  confusion  might  be  caused  by  the  diMinction  between  model 
semarUics  and  model  notatioa 

To  resolve  the  data  model  ambiguities,  a  refemice  framework  was  used.  In  this  founework  the 
following  modelling  concepts  are  included:  records,  record  references  or  ctmstraints,  compt^tes 
(aggregation),  subtypes  and  views.  FOr  each  of  dtese  concepts  the  corresponding  data  modelling 
facilities  of  a  particular  repository  have  been  ittentifled.  However,  scrnie  of  the  concepts  cannot  be 
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realized  in  a  particular  repository.  The  results  of  this  data  model  comparison  were  summarized  in 
a  table  included  in  the  final  report  of  the  study. 


4 


TOOL-BUILDERS*  DAY,  FRIDAY  27  SEPTEMBER  1991 


On  the  Tool-Builders'  Day,  the  last  day  of  the  conference,  several  tool-builders  desctibed  their 
experiences  with  the  Integration  of  their  tools  In  PCTB-based  environments.  At  the  start  of  the  . 
day,  there  were  two  more  general  talks;  one  on  tool  documentation,  the  other  giving  an 
introduction  to  PCTE.  In  general,  PCTE  was  considered  a  very  useful  backtxHie  for  integrating 
CASE  tools.  However,  a  need  was  felt  for  more  guidance,  for  instance,  in  the  form  of  migration 
guides. 

4.1  Documenting  tools  for  PCTE  based  environments 

Speaker:  Mias  Margaret  AMIa 

The  fundamental  purpose  of  documentation  is  to  give  the  user  knowledge  needed  to  support  his 
actual  tasks.  Three  major  requirements  that  the  documentation  should  meet  can  be  given.  When  a 
user  needs  information,  he  wants  to  spend  as  little  time  as  possible  getting  it.  So  the 
documentation  needs  to  be  accessible,  accurate,  arxl  complete,  and  needs  to  present  its 
information  in  the  users'  terms.  From  the  software  supplier's  point  of  view,  documentation 
creation,  maintenance  and  delivery  need  to  be  trouble-free  and  economical.  Furthermore,  the 
documentation  is  expeaed  to  fulfil  a  marketing  role  in  promoting  the  image  of  the  product  and 
the  supplier. 

Commonly,  three  dimensions  are  distinguished  in  integration  of  tools  in  an  environment  like 
PCTE.  These  three  dimensions  have  their  own  impact  on  documentation.  Integration  of 
presentation  means  that  several  tools  have  the  same  look  and  feel'.  So  it's  often  not  possible  for  a 
tool-builder  to  document  the  way  the  user  sees  the  tool.  Data  integration  implies  that  data  can 
have  meaning  beyond  the  functionality  of  a  specific  tool.  This  fact  can  have  an  important  impact 
on  documentation.  Because  tools  tend  to  be  functionally  integrated,  tool  boundaries  start  to 
disappear  and  documentation  has  to  be  'task-oriented'  rather  than  'tool-oriented'.  So  it  seems  to  be 
useful  to  add  a  fourth  dimension  to  the  tool  integration  space:  the  documentation  integration. 

As  PCTE  is  taken  up  more  widely.  Integration  activities  are  less  and  less  to  be  performed  with 
close  cooperation.  In  this  situation  definition  of  responsibilities  and  roles  for  integration  including 
integration  of  documentation  is  very  important.  In  general,  tool-builders  have  to  provide  tools, 
data  models  and  documentation  in  an  integratabie  form.  Environment-builders  are  to  form  an 
integrated  whole. 

Implicit  in  the  integratiem  process  is  some  degree  of  reusability  of  documentation.  In  this  ctmtext 
there  are  many  technical  issues  like  interchange  standards  and  conflguratiCHi  management  One  of 
the  most  difficult  problems  is  the  context-sensitiveness  of  parts  of  docum«itation:  a  (riece  of  text 
or  a  diagram  in  one  context  does  not  necessarily  mean  the  same  as  it  does  in  another  context 
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4.2  PCTE  for  tool'builders 

Sptalur:  Mr  R4gli  Minot 

From  the  usef*u  point  of  view  a  PCTE  tool  is  a  program  suppoiting  one  or  more  activities  of  ttie 
software  development  process  that  can  be  potted  to  any  PCrB>based  environment  Two  types  of 
tools  can  be  disUnguished.  Horizontal  tools,  on  the  one  hand,  are  tools  applicable  in  all  phases  of 
the  software  development  process.  Examples  of  hoiizmital  tools  are  version  management  tocfls 
and  documentation  su|qx)it  tools.  Vertical  tools,  on  the  other  hand,  are  tocds  dedicated  to  a 
specific  phase  in  the  software  development  process.  Examines  of  vertical  tools  are  design  tools 
and  maintenance  support  tools. 

From  a  tool-buildei's  point  of  view  a  PCTE  tool  is  a  program  designed  to  be  ported  and  integrated 
in  a  PCTE  based  environment  Several  levels  of  portability  can  be  distinguished.  At  the  highest 
ievel.  a  PCTE  tool  directly  invokes  PCTE  and  XU  operations.  Tools  at  this  level  can  be  directly 
ported  to  all  PCTE  implementations.  At  the  second  level  a  PCTE  tool  invokes  operations  of 
common  services  built  on  top  of  PCTE  and  XI 1  (like  the  Broadcast  Message  Server  (BMS) 
OPEN  LOOK  or  MOTIF).  Portability  of  such  tools  is  achieved  through  the  portability  of  these 
common  services.  At  the  third  level,  a  PCTE  tool  invokes  other  PCTE  tools  or  tool  components. 
Pcnabiiity  of  such  tools  is  achieved  by  portability  of  the  tools  or  tool  components.  At  the  fourth 
and  lowest  level,  a  PCTE  tool  invokes  foreign  tools.  Portability  of  tools  at  this  level  depends  on 
portability  of  the  foreign  tools. 

Besides  levels  of  portability  also  degrees  of  integration  can  be  distinguished.  At  the  highest  level, 
a  PCTE  tool  is  designed  to  be  integrated  with  a  specific  PCTTE  environment^.  Tools  at  this  degree 
of  integration  must  have  knowledge  of  existing  data  structures  and  have  to  be  designed  to  be 
plugged  in  existing  schemas.  At  the  second  level,  a  PCTE  tool  is  designed  to  be  integrated  in  a 
PCTE  framework^  which  offers  certain  services.  Of  course  such  tools  can  only  be  integrated  in 
frameworks  providing  these  services.  At  the  third  and  lowest  level  of  integration,  a  tool  is 
designed  to  be  integrated  in  any  PCTE  based  framework  or  environment  In  this  situation  only 
few  hypotheses  on  other  tools  and  schemas  have  to  be  made.  Tfie  design  of  the  tool's  private 
schemas  must  be  made  in  strong  isolation. 


^An  (anvinamiem  CM  be  defined  u  t  Mt  of  venicil  looli  Imib  on  up  of  ■  fraiMwo<tc. 
fnnieiMMk  cen  be  defined  horixoMei  loolt  and  cmwiwn 
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Three  dimensions  of  integration  can  be  distinguished^:  dau  integration,  control  integration  and 
user  interface  integration.  In  general  the  design  of  a  PCTE  tool  can  be  done  by  peifonning  the 
following  steps; 
data  integration 

design  your  data  schema 
specify  invariant  semantics 
control  integration 

associate  operation  with  data 
user  interface  integration 

design  interaction  with  user 
relate  interaction  with  operations 

At  the  end  of  his  presentation  Mr  Minot  summari^  Emeraude's  experience  with  PCTE  tool 
design; 

tools  must  be  designed  with  integration  considerations; 

through  the  QMS,  PCTE  solves  a  large  part  of  data  integration  problems  which  otherwise 

would  imply  high  development  costs; 

error  recovery  is  considerable  simplified  with  transactions; 

transparent  distribution  and  concurrent  access  are  managed  by  PCTE  with  almost  no  cost  for 
tool  builders; 

PCTE  tools  can  access  foreign  systems  (e  g.  Unix  file  systems)  and  call  foreign  tools  in  a 
controlled  and  portable  way  (encapsulation): 
performance  is  dose  to  nadve  system  performance; 

PCTE  must  be  complemented  by  a  UI  presentation  package  and  possible  higher  level  ctxitrol 
integration  services. 

4  T  PME:  The  Project  Management  Environment 

Sptaktr:  Dr  Him  E.  Ktus 

In  the  context  of  the  assessment  i^tase  of  PCTE4'  programme  two  projects  have  been  planned  by 
(he  Netherlands  industry.  The  fiist  project  is  the  development  of  a  Project  Management 
Environment  (PME).  The  project,  staited  in  May  1989,  will  end  in  March  1992  and  is  undertaken 
by  Westmount  Technology.  To  carry  out  the  second  project  this  organization  is  complonentod  by 
BSO/Aerospace  ik  Systems.  The  purpose  of  this  project  is  to  carry  out  a  real  life  cyde  project  to 
assess  PCTE  fit»n  an  environment  usKtr's  point  of  view. 

The  purpose  of  the  PME  projea  is  to  develop  a  (Moject  management  workbench.  The  woitbendi 
is  to  nin  on  Unix-s  and  VMS-based  PCTE.  aim  of  the  develoixnent  is  to  assess  PCTE  ftom  a 
tool  builder’s  point  of  view.  The  PME  to  be  developed  is  an  interactive,  multi-window 
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management  woikbench  with  ftmctlonalities  for  oiganization  modelling,  resource  modelling,  user 
role  modelling,  project  definitions,  planning,  monitoring  and  repotting. 

One  of  tlie  PCTE  shortcomings  experienced  during  the  project  was  the  lack  of  a  fine  grain  object 
quei>  language.  Fuithennore,  the  need  was  felt  for  standard  public  SDSs  and  tool  migration 
guide-lines.  SDSs  are  necessary  (but  not  sufficient)  for  easy  and  successfiil  tool  integration.  In 
general,  there  is  a  growing  acceptance  of  PCTE.  Further  standardization  (ISO)  may  be  coixlucive 
to  further  acceptance.  PCTE  can  be  very  beneficial  for  an  open  architecture. 

4.4  A  Broadcast  Message  Server  on  PCTE 

Sp«akcr:  Paul  Vkkcn 

HP  combined  the  tool  integration  facilities  offered  by  three  mature  CASE  integration 
technologies:  PCTE  (providing  Data  Repository  Services  and  Data  Integration  Services),  Motif 
(providing  User  Interlace  Services)  and  HP's  SoftBench  (providing  Message  Services  and  Task 
Management  Services).  SoftBench  is  an  extertrible  and  easy-to-use  environment.  The  tool 
integration  framework  contains  an  integrated  set  of  tools  for  program  construction,  program 
arudysis  and  version  management.  Third  party  tools  covering  the  lifecycle  are  integrated  in  the 
framework. 

HP  re-implemented  the  SoftBench  Message  Server  on  top  of  PCTE,  to  produce  an  open 
framework  that  provides  control  integration.  The  functional  behaviour  of  a  BMS  environment  is 
as  follows:  tools  register  their  interest  in  particular  messages.  Tools  also  send  messages  to  the 
BMS  that  selectively  broadcasts  them.  A  tool  can  respond  to  appropriate  messages  in  return. 

The  BMS  approach  described  above  is  conceptually  simple  and  doesn't  insert  any  significant 
performance  overhead.  It  provides  a  flexible,  evolutionary  way  for  tools  designed  indepetKlently 
to  cooperate.  The  SoftBench  BMS  uses  PCTTE  facilities  for  process  execution  and  inter-process 
communication. 

HP's  major  experience  with  PCTE  is  that  PCTE  does  provide  help  for  the  tool-writer  although  (or 
may  be  thanks  to  the  fact  that)  tool-writers  have  to  make  engineering  trade-offs.  Migration  of 
tools  from  Unix  to  PCTE  is  possible  because  there  are  pragmatic  solutions  for  interworking 
between  PCTE  and  Unix.  At  the  moment  there  is  not  enough  suj^rt  availaUe  for  PCTE 
tool-writers.  FOr  example,  more  guidance  is  needed  chi  design,  performance  optimizatimi  and 
migration.  A  PCTE  user  group  may  be  useftil  to  share  eiqreriences  and  to  agree  cm  sdiemas.  HP 
will  follow  the  ^^roach  described  above  for  its  firamevrork  product 
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4 J  The  ENTREPRISE II  environment 

SpMktrt  Dr  Anaiiry  Ltgalt 

The  ENTREntlSE  11  environment  is  an  n^E  supporting  management  and  amtrol  of 
development  and  maintenance.  The  environment  has  been  created  under  pressure  of  leal-iife 
users. 


The  requirements  on  the  IPSE  emanate  from  two  issues.  Rretly.  the  development  of  die  IPSE  is  a 
very  large  project.  In  the  project  several  industries  with  differing  nadonalides  cooperate.  The  sites 
concerning  the  projea  are  highly  distributed.  Ftirthennore.  the  system  to  be  developed  has  a  very 
long  life.  In  such  a  project  management  of  costs,  delays,  quality  and  maintenance  is  a  hard  job. 

From  this  first  issue  the  following  requirements  can  be  distilled: 
standards  must  be  used  throughout  the  project; 
the  solution  must  be  portable; 
the  IPSE  configuration  must  be  managed; 
the  maintenance  of  the  IPSE  must  be  managed. 

The  second  requirements  issue  is  "integration'*.  The  best  known  integration  factors  are  die 
technical  factors.  Four  technical  integration  factors  can  be  distinguished. 

Data  integration  can  be  achieved  at  various  levels.  Firstly,  the  tools  are  data'integrated  by 
hosting  them.  Secondly,  the  tools  are  data-integrated  by  integrating  them  on  PCTE.  Thirdly, 
the  tools  are  data>integrated  by  integrating  them  information  system  part  of  the  IPSE. 
Presentation  integration  results  in  a  consistent  interaction  with  all  tools.  ENTREPRISE  II 
uses  OPEN  LOOK  and  MOTIF. 

Process  integration  is  achieved  by  defining  roles  and  tools  and  by  declaring  tools. 

Openness  is  the  last  technical  integration  factor.  The  IPSE  has  to  be  open  to  foreign  data,  to 
foreign  tools  and  to  other  User  Interfaces.  Gearly,  there  is  a  strong  relationship  between 
openness  and  the  other  three  technical  integration  factors. 

Non-technical  integration  factors  are  often  more  important  and  hard  to  meet  than  die  technical 
ones.  Impo.tant  examples  of  these  factors  are: 

Costs 

Delays 

Industrial  property 
Maintenance  of  the  IPSE 

The  framework  of  ENTREBUSE II  ctmsists  of  an  information  management  part,  a  process 
managraient  part  and  a  reuse  managemou  part  These  parts  are  integrmed  tmte^of  PCTE  1.5 
(hosted  (HI  Unix)  and  ure  a  common  user  interftme.  The  environmoit  is  ctmiidet^  by 
configunditm  managnnatt,  documentation  managnnait  uid  {Hoject  muiagemeid  tools  smd  a  set 
of  tools  sufq^rting  the  various  phases  in  the  develqpmerd  {KOOMS. 
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VULCAN/AD  •  Analysis  and  Daslgn  Tool 
SpMlur:  Mr  B.P.  Bhat 


VULCAN  is  a  CASE  Environment  providing  an  integrated  set  of  CASE  ftmctions.  The  basic 
support  for  these  functions  is  provided  by  common  service  modules  like  presentation  and  user 
interface  services,  and  object  management  services. 

The  core  of  the  architecture  consists  of  a  repository  containing  all  user-provided  and  generated 
information  related  to  projects.  This  ensures  the  integrity  of  the  data  and  provides  a  means  of 
enforcing  security  constraints.  The  functional  Reifications  of  the  repository  are  based  on  the 
PCTE+  model. 

The  Object  Management  System  consists  of  a  set  of  access  routines  built  over  the  repository  to 
provide  users  and  CASE  tool  developers  an  object-oriented  view  of  the  data  contained  in  the 
repository. 

VULCAN  has  a  Graphical  User  Interface  (GUI).  The  OUI  is  consistent  and  uniform  across  all 
fuTKtions  and  tools  of  the  environment  It  is  based  on  OSF/MOTIF  and  the  underlying  X 
Windows  System.  In  addition,  a  command  language  allows  users  to  access  tool  functions  without 
going  through  the  GUI. 

The  Application  Programming  Interface  (API)  consists  of  a  collection  of  C-h*  class  definitions 
and  functions  to  access  and  manipulate  objects  in  the  VULCAN  environment 
A  Direct  Repository  Interface  is  provided  to  enable  other  tools  to  store  and  retrieve  information  in 
the  VULCAN  repository.  It  consists  of  a  collection  of  C-bindings  to  access  PCTE-f  services. 

The  Tool  Integration  Ser\'ice  is  designed  to  accommodate  new  tools  within  VULCAN  by 
extending  the  user  interface.  It  will  be  possible  to  integrate  a  new  tool  and  still  maintain 
consistency  with  the  rest  of  the  tools  in  the  environment. 

VULCAN  is  intended  to  provide  extensive  software  engineering  support,  and  is  expected  to  meet 
the  needs  of  various  classes  of  users,  including  software  project  managers,  analysts,  designers, 
programmers,  testing  &.  validation  staff,  maintenance  staff,  etc. 

4.7  Tool  Integration 

Sptalurs  Mr  Bryan  BaadtU 

Integration  within  a  project  support  environmoit  cm  be  defined  as: 

"Integratkm  ocmcems  the  degree  of  ooheidon  and  fnieracUtm  of  components  within  die 
{Hojea  wpport  mvironment,  such  diat  the  envlroranem  qipeais  coherertt  to  the  user." 

Four  different  types  of  integration  can  be  distinguished:  functional,  data,  otmtrol  and  (nesentation 
integration.  Besides  these  integratkm  types,  two  differem  dimanirms  integratitm  can  be  achieved 
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in,  can  be  distinguished:  horizontal  and  vertical.  Horizontal  integration  is  mutual  integration  of 
tools.  Vertical  integration  is  integration  of  tools  and  support  services. 

Vertical  Integration  can  be  iq;)pfoached  in  different  ways.  The  ai^roach  spectrum  varies  from 
Foreign  process  integration  via  Interface  layer  integration  to  Source  port  integration.  Foreign 
process  integration  is  a  very  loose  and  ctmap  type  of  integration.  An  example  of  foreign  process 
integration  is  integration  of  an  Ada  compiler  with  an  operating  system  like  VMS.  This  integration 
is  relatively  cheap  because  there  is  no  need  for  re-validation  of  the  compiler.  Interface  layer 
integration  is  a  relatively  loose  type  of  integration.  An  existing  tool  is  enc^rsulated  in  an  interface 
layer.  This  type  of  integration  degrades  the  performance  because  of  translation  by  the  interface 
layer.  Horizontal  integration  of  tools  can  not  easily  be  combined  with  interface  layer  integration. 
Source  port  integration  is  a  very  tight  and  expensive  type  of  vertical  integration.  Horizontal 
integration  of  source  port  integrated  tools  can  be  achieved  relatively  easy. 


Vertical  Integration 

Horizontal  Integration 

Functional 

UM  of  facilities  of  PCTE 

Tether  then  OS  (independent 
security  policy) 

interoperability  without 
redundancy,  duidication  or 

omiuions 

Data 

use  of  OMS  for  persistoit  data 
(schema  definitions) 

common  formats  supporting 
concurrent  and  multiple  aoceu 

Control 

use  of  invocation,  stdieduUng, 
executioa..  (transactions  and 

rollbacks) 

process  management 

Presentation 

unifonnity  of  interacdon, 
manipulation  and  presentation 
ofdau 

common  style  of  preaentaticn 

and  interaction 

4,8  STAR:  the  requirements  analysis  environment 

Sptakcri  Dr  Ayt&l  Er^  D 


Turicey  entered  die  PCTEf  {Hoject  in  the  assessment  phase  in  October  1988.  The  comributicm  to 
the  pMoject  is  to  develqi  a  requiremmit  analyris  tool  under  Unix,  to  port  diat  to(d  to  PCT&t>,  and 
to  assess  the  potting  process. 


The  requirement  analysis  tool  is  STAR  (STructured  Analysis  of  Requirements).  STAR  supports 
the  structured  modelling  of  information  systems  and  real-time  systems.  The  tool  supports  data 
modelling  (ERD)  and  activity  modelling  (control  flour  diagram  and  time  dependency  charts). 
Currently,  a  prototype  of  the  Unix  version  of  STAR  is  finished.  The  design  of  the  PCTE-t-  version 
of  STAR  is  going  on.  This  version  is  planned  to  be  ready  in  February  1992. 

A  few  problems  have  been  encountered  during  the  port  to  PCTE+,  as  there  are  lack  of  sufficient 
porting  guidance  and  of  C-m-  bindings. 

4.9  Early  feedbacks  fki>m  the  assessment  phase 

Speaker:  Mr  Girard  Boudkr 

In  the  years  1987  and  1988  PCTE  releases  1.4  and  1.5  provided  input  for  the  definitions  jrfiase  of 
PCTE-i-.  During  the  years  1989  up  to  1992  PCTE-t-  will  be  assessed.  In  parallel,  EC^A  PCTE  will 
developed.  PCTEh-  and  its  assessment  will  provide  irq)ut  for  this  development. 

The  PCTE-t-  assessment  is  an  international  collaborative  effort  of  several  cooperating  nations.  Its 
objectives  are: 

to  assess  the  implementability,  usability  and  effectiveness  of  the  PCTE-t-  specification; 
to  guide  revision  and  completion  of  the  PCTE-f  specification; 
to  provide  sufficient  confidence  to  support  the  promotion  of  the  final  specification  as  an 
international  standard. 

Within  the  assessment  phase  three  main  activities  can  be  distinguished.  Hrstly,  a  number  of 
PCTE-t-  implementations  are  developed,  eminently,  a  SUN/Unix  implementation  is  available.  A 
VAXA'MS  version  will  be  available  mid  1992.  Secondly,  PCTE-t-  based  tools  are  provided. 
Thirdly,  the  proper  work  in  the  assessment  pduise  is  assessment  work.  'Unt  resulting  assessment  is 
based  on  the  first  two  activities.  Assessment  also  results  from  porting  of  tools  fiom  one  interface 
implementation  to  another. 

The  output  of  the  assessment  i^tase  is  twofold.  During  the  assessment  phase  commoits  mi  the 
PCT&f  specification  are  submitted  to  the  PCTE-t-  Definition  Team.  The  second  ouqmt  component 
is  a  final  assessment  report  produced  at  the  end  of  the  assessment  phase.  In  faa  this  final  report 
will  be  a  synthetic  summary  of  all  contributor's  assessments. 

Before  a  comment  is  inserted  in  the  several  assessment  documents  modifications,  responses  and 
changes  may  be  added  to  it.  and  it  is  reviewed  by  the  Definition  Team. 

Hie  relatimiships  with  ECMA  TC33  are: 

TA- 13  is  represented  in  the  ECMA  TC33  committee; 

several  members  (or  ex-inembers)  of  the  PCTE-f  Definition  Team  paiticiiutte  in  die  ECMA 
TC33m3EP  workshops; 

-  aU  appropriate  documents  (PCTE^/Ill.PCTEf-A:X)NREP  and  PCTEf/CHANOES)  are  sent 
toECMATC33; 
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some  comments  on  the  PCTE-f  specifications  have  already  been  taken  into  account  in  the 
ECMA  PCTE  abstract  specifications. 

4.10  Porting  Arcs  to  PCTE,  practical  experiences 

Speaker:  Mr  Aadere  Lumlkvlal 

Arcs  is  an  Ada  Programming  SuKX>tt  Environment  (APSE),  which  is  'data'integrated'  with  the 
Telesoft  Ada  (jompiler  TeleGen2.  In  this  context  data-integrated  means  that  Arcs  woiks  on  the 
same  internal  data  structures  as  does  the  compiler. 

Telia  Research'^  ported  the  APSE  from  Unix  to  PCTE.  The  porting  strategy  was: 

1 .  make  a  first  port  of  Arcs  and  TeleGen2  using  a  solution  as  simple  as  possible; 

2.  use  ported  environment  as  develoi»nent  environment; 

3.  start  exploring  the  facilities  provided  by  PCTE. 

Following  this  strategy  some  sort  of  evolutionary  i^roach  has  been  adopted.  The  advantage  of 
this  approach  is  that  always  a  woridng  APSE  is  available  and  it  can  be  tested  continuously. 

For  the  first  simple  port,  a  one-to-one  mt^^ing  of  Unix  files  on  PCTE  objects  was  used  because  a 
granularity  decision  can  have  high  impact  on  the  required  effort.  Besides  the  mapping  some 
change  appeared  to  be  necessary  in  naming  conventions  and  command  syntax.  In  this  first  potted 
version  the  PCTE  QMS  is  used  in  a  very  simple  way.  Some  advantages  of  this  usage  of  QMS  can 
be  given  already: 

referential  integrity; 

sharing  of  sublibrarics  between  libraries  is  made  explicit; 
sharing  of  source  text  between  sublibraries  is  made  explicit. 

4.1 1  The  AdaNICE  toolset  on  PCTE 
Speaker:  Mr  Nando  Gallo 


AdaNICE  is  a  set  of  tools  related  to  systmn  design.  The  toolset  is  compliant  with  HOOD  Version 
1.3.  It  su];qx)rts  reuse  of  design,  design  metrics,  template  driven  design  document  generation  and 
code  generation.  AdaNICE  is  highly  user  ccmfigurable  and  open  to  integradcHi  with  external  tools. 

Within  AdaNICE,  a  project  can  be  partitioned  into  subprojects  in  order  to  allow  pardlel 
developments.  The  tools  are  'presentatiem  integrated'  using  a  Dialogue  Manager.  This  Dialogue 
Manager  is  built  on  top  of  X/1 1.  By  sharing  a  database  the  tools  are  'dida-tattegrated'.  This 
daubase  is  partitioned  in  two  parts:  a  Run  Time  Data  Base  (RTDB)  and  a  HOOD  Project  Litxary 
(HPL).  The  HPL  is  encqrsulated  in  a  HPL  Manager.  This  HKAf  provide  a  logical  itiMtsentaticHi 
of  the  Project  Ubrary  independent  frenn  the  kind  of  rqpositmy  and  ttie  physical  rquesentatiem  in 


‘^TiSk  RMMfck  ii  IIM  MW  IWMICII  wbii««y  of  SwidUi  IUmor  AdmUimiioii  (T^mwImi).  TUrraAM  k  ilw  owMrofTdiSoft.  Om  SwAfah 
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the  repository.  The  RTDB  enables  efficient  displaying  of  graphical  information  and  hides  and 
ceiiualizes  implementation  decisions  related  to  load/save  approaches. 

Loading  information  from  and  saving  information  to  the  HPL  can  be  done  in  two  ways,  either  in  a 
single  step  or  incrementally.  The  single  step  approach  woiks  as  follows;  when  a  sulH>roject  starts, 
all  information  needed  is  loaded  from  the  HPL  into  the  RTDB.  All  HPL  updates  are  stored 
tnnporarily  in  a  so  called  Working  Area.  When  the  subproject  is  committed  the  HPL  will  be 
{lermanently  updated.  In  the  incremental  ai^roach  the  information  will  be  loaded  incrementally 
from  the  HPL  into  the  RTDB.  The  updates  fo  die  HPL  will  also  be  saved  incrementally  to  the 
liPL.  All  updates  can  be  cancelled,  however,  before  the  subproject  is  committed. 

'Ihe  HPL  is  implemented  on  the  OS  file  system.  Structural  information  of  a  subproject  is  stored  in 
a  Master  file.  Additional  information  on  HOOD  objects  is  stored  in  secondary  files.  The  Master 
file  is  loaded  when  the  subproject  is  opened,  creating  the  RTDB  in  the  core  memory.  Secondary 
files  are  loaded  when  needed. 

Porting  die  AdaNICE  toolset  to  PCTTE  there  are  four  possible  organizations  of  the  database: 

1 .  represent  the  HPL  structure  in  die  OMS  as  it  is  on  the  File  System,  defining  a  "Unix 
emulation"  schema; 

2.  represent  only  HOOD  objects  and  their  include  and  use  relations  as  OMS  objects  and 
relationships; 

3.  represent  major  HOOD  entities  (objects,  operations,  operation  sets,  require  interfaces,  etc.) 
as  OMS  objects  and  their  relations  as  OMS  relationships; 

4.  represent  all  HOOD  entities  (3^types,  constants,  operation  parameters  etc.)  as  OMS  objects 
and  their  relations  as  OMS  relationships. 

To  decide  which  one  of  the  four  organizations  is  the  best  one,  three  evaluation  criteria  have  been 
used; 

A.  openradnessfintegratability 

B.  efficiency 

C.  poning/implementation  cost. 

Based  on  these  criteria  the  third  organization  has  been  selected  because  this  orgtmizatimi: 

allows  to  achieve  a  high  degree  of  openendness  and  of  integrataUlity  of  the  toolset,  since  the 

most  relevant  information  is  described  in  the  schema; 

allows  to  ftiUy  exploit  and  assess  die  capabilities  of  PCTE; 

allows  to  achieve  an  accqitable  level  of  efficiency  through  a  proper  run-time  ditta 

organizaticm: 

-  introduces  Mceptidile  implem«itation  cost  and  design  complexity. 
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Assessing  the  PCTE  OMS  a  few  problems  have  been  encountered. 

Link’s  Keys  cannot  be  changed  (specification  bug). 

There  are  no  facilities  for  defining  an  order  among  links  and  for  sorting  links  (missing 
feature). 

The  possibility  to  define  light-weight  objects  with  a  reduced  set  of  pre-defined  attributes  has 
been  missed. 

Some  of  the  PCTTE  OMS  feamres  have  proven  to  be  paiticulaiiy  useful,  since  they  include:  nested 
transactions  and  SDS/Working  Sdiema  mechanisms  (to  separate  between  AdaNICE  internal  view 
and  'public'  view  (interface  with  other  tools)). 
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KXDNXSJDUiy  25  SMPIKHBMR  DSCZSIOK-tatORa  •  DAY 

Choima/i  Dick  Fikkmrt,  TNO  Phyaioa  and  Elmctronioa  Laboratory,  Tba  Nmthmrlanda 

07.45  Bus  departs  from  Juno  Hotel 
07.30  •  16.00  Registration 
(%.30  -  08.50  Spiers'  Meeting  (Secretariat) 

09.00  <  17.45  Exhibition 

09.00  Welcome  and  Opening  Address 

MrP.Spohr 

TNO  Physics  and  Electronics  Laboratory,  The  Netherlands 

Organizations  behind  PCTE 

09.20  PCTE  Standardisation 
Mr  Myer  W.  Morron 

BNR  Europe.  UK 

lEPG  TA.13 
Dr  Brian  Gladman 


Ministry  of  Defence,  UK 

PCTE  is  the  Open  Repository 
Mr  Robert  Cochran  Managing  Director 

Executive  Committee  of  PIMB 
Chairman  PCTE  Promotion  Croup 

Catalyst  Software,  Ireland 

This  paper  will  outline  the  rapidly  accelerating  momentum  in  support  of  PCTE  and  will  show  how 
the  PCTE  community  (and  in  particular  PIMB  and  PPG)  have  b^n  one  of  the  instruments  of  this 
success. 

Commission  of  the  European  Communities 
Mr  D.  Talbot 

DC  XIH,  Tll&l  and  ESPRIT 
CEC,  Belgium 

10.40-  11.15  Coffee  Break 

Industrial  PCTE  Strategy 
11.15  Digital's  PCTE  Strategy 

Mr  lAtciano  Vernocchi  CASE  Senior  Product  Manager 

Software  Development  Technology  Group 
Digital  Equipment  Corporation.  Italy 

PCTE  as  HP's  CASE  Repository 
Mr  George  Tatge 

Software  Eningineering  Systems  Division 
Hewlett  Packed  Company.  USA 


Framework  Interoperability 
Program  Manager 


Chairman 

Independent  European  Programme  Croup, 
Technical  Area  13  (lEPG  TA-13) 


Director 


Director  Systems  Strategy 
Chairman  ECM A  TC33 
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BAe  (MA)L  Polky  for  Software  Engineering  Environments 

MrPhilThornley  Principal  Engineer 

British  Aerospace  (Military  Aircrafi)  Ltd.,  UK 

The  presentaUon  describes  experience  with  Eurofighter  DPSE.  current  research  work,  and  future 
requirements. 

Need  for  Standard » IBM  Viewpoint 

Mr  Gemudn  Sagob  Senior  Consultant 

European  AIX  CASE  Center 
IBM,  France 

IBM  are  now  committed  to  open  systems  as  a  strategy  direction.  For  the  fiiture  IBM's  intenrimi  is 
to  populate  the  ECMA  Reference  Model  witli  a  standardized  system  or  interface.  At  present  a 
stantiard  for  data  repository  services  exists  in  the  form  of  PCTE,  while  IEEE  POSIX  is  a  standard 
operating  system  defmition. 

12.45  -  14.CX)  Lunrh 

13.30  -  13.50  Speakers' Meeting  (Secretariat) 

The  STARS  Program  ai»d  PCTE 

Dr  John  F.  Kramer  Program  Manager  (STARSISEI) 

Software  and  Intelligent  Systems  Technology  Office  (SISTO) 

Defense  Advanced  Research  Projects  Agency  (DARPA),  USA 

The  Software  Tedmoiogy  for  Adaptable,  Reliable  Systems  (STARS)  program  is  a  US  DARPA 
program  to  develop,  integrate  and  demonstrate  advanced  software  engineering  technology.  As  pan 
of  the  program,  STARS  will  demonstrate  three  integrated  Software  Engineering  Enviitximents  on 
three  real  applications. 

STARS  is  part  of  a  larger  effort  including  STARS,  the  Software  Engineering  Institute  (SEI)  and  the 
US  Ada  Program. 

14.20  Pane! 

Tedinology  Push,  Smart  Buyers,  and  Market  Pull.  The  h'orces  Accelerating  PCTE? 

Chairnun 

Mr  E.  van  Hcek  Director 

Defence  Rssea<'ch  end  Development  (DWOO) 

Ministry  of  Defence,  The  Netherlands 

Members 

Mr  Ian  G.  Campbell  Mr  David  Talbot 

Mr  Myer  V/.  Morron  Mr  George  Tatge 

Mr  Germain  Sagob  Mr  Luciano  Vernocchi 

15.45  -  16.15  Tea  Break 

16.15  A  Management  Introduction  to  PCTE 

Mr  Ian  G.  CampbeU  Managing  Director 

Emeraude,  France 

17.15  End  of  Sessions 

1 8.00  Busses  depart  to  City  Receptiem 

1 8.45  Recet^on  Offered  by  the  City  of  The  Hague 

20. 15  Busses  depart  to  the  Hotels 
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Ch»im»n  Prof,  Dr  Vdo  X»ltmr,  Vnivrmity  of  H»g»n,  Goraany 

08.00  Bus  depGits  from  Juno  Hotel 

08.00  >  16.00  Registration 

08.30  -  08.50  Spiers' Meeting  (Secretariat) 

09.00  •  17.00  ExhibiUon 

09.00  To  Build  an  Envlrtminent  on  top  of  PCTE 

PrcfessorJ.C.Dernianu 
CRIN’University  of  Nancy,  France 

Ihe  experience  of  the  ALF  project  development,  a  software  process  model  centered  development 
enviionment,  allows  some  cortclusions  on  the  useftilnem  of  PCTE. 

Meeting  User  Requirements  for  Control  in  a  Large  Scale  IPSE 

Mr  Martin  Kirby  Technical  Architect  •  PC7t  'E+  Assessment 

SD^cicon  Ltd.,  UK 

The  speaker  will  describe  the  m«\jor  control  requirements  for  the  IPSE  in  support  of  the  Eujofighter 
Aircraft  Project.  The  ease  with  which  tliese  can  be  met  by  PCTE  will  be  demonstrated  and  benefits 
to  the  application  builder  described. 

EAST  Environment 

Mr  Jean-Philippe  Bourguignon  Managing  Director 

SFGL,  France 

'fhe  EAST  Environment  is  an  open,  integrated  environment  exploiting  PCTE  to  achieve  a  high 
level  of  flexibility. 

10.30  -  11.00  Coffee  Break 

11.00  Object  Granularity  its  the  Concerto  Repository 

Mr  Edouard  Andri  Concerto  Product  Manager 

SEMi  Group,  France 

The  Case  Data  Interchange  Format  (CDiF)  Standards 

Mr  Mike  Imber  Consultant 

Chairnuot  CDIF  Techniced  Committee 

RJcD  Group 
LBMS,  UK 

The  talk  will  cover  the  CDIF  standards  and  their  relevance  to  PCiE. 
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12.00  -  13.30  Lunch 

13.00  *  13.20  Speakers' Meeting  (Secreuriat) 

13  JO  Toolbullder  and  the  Open  Repository 

Mr  Paul  Harris  Consultant 

IPSrS  Softwar  e  PLC,  UK 

Implementation  of  a  Complex  Software  Development  Environment  •  EPOS  In  a  PCTE-t- 
Environment 

Mr  H.G.  Rau  SeMor  Consultant 

GPP  GesellschaftfUr 

Prozessrechnerprogrammieruftg  ntbH,  Germany 

Some  remarks  cm  the  implementation  goals  of  a  complex  CASE  tool,  the  benefit  expected  from 
PCTE-f  use  and  the  implementation  problems  envisaged. 

PCTE  Training  -  Experiences  of  UCW  Aberystwyth 

Dr  Mark  Ratcliffe  Lecturer 

University  College  of  Wales,  UK 

15.00  -  15.30  TeaBreak 
IS  JO  The  HyperWeb  Project 

Dr  Gerard  Mertani  CASE  Mission  Manager 

Bull,  USA 

Comparing  Current  Repository  Offerings  (PCTE,  IBM  RM,  IRDS) 

Mr  Jean  B^rubi  Principal  Consultant 

Orsand  Ltd.,  UK 

The  presentation  introduces  the  approach,  identifies  key  items  in  the  comparison,  and  concludes  on 
the  potential  of  open  repository  environments. 

1 6. 30  End  of  Sessions 

17.15  Bus  departs  to  Juno  Hotel 

19.00  BoF  8es8ion(s) 

PCTE  meets  CFI? 
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naxuky,  27  SEPTEMm  tool-builders'  day 

Chairntn  Hugh  Davis,  ICL,  UK 

08.00  Bus  depans  ftom  Juno  Hotel 

08.30  ‘  12.00  Registration 

09.00  •  16.30  ExhiMUon 

08.30  •  08.S0  Speakers' Meeting  (Secretariat) 

09.00  Documenting  Tools  for  PCTE^based  Environments 

Ms.  Margaret  Aldti  Partner 

Syntagma,  UK 

Syntagma  is  a  small  UK«boanl  organisation  which  designs,  writes  and  produces  user 
documentation.  Syntagma's  PCTE*based  woik  includes  the  PACT  user  documentation, 

'Introducing  PCT&f'.  and  documentation  for  Emeraude,  Eniiq)rise  II  and  EAST. 

PCTE  for  Tool'Builders 

Mr  R.  Minot  Technical  Director 

Emeraude 

PME:  The  Project  Management  Environment 

DrHansE.Keus  Manager  Strategic  Developments 

Westmount  Technology  B.V.,  The  Netherlands 

The  PME  developed  on  the  PCTE-f  platfomt  will  become  part  of  the  existing  ICASE  toolsets 
which  include  complete  documentation  facilities  and  belongs  to  the  most  comprehensive  Software 
Engineering  Environments  available  on  UNIX  tmd  VMS  platforms. 

10.30^  11.00  Coffee  Break 

11.00  A  Broadcast  Message  Server  on  PCTE 

Mr  Paul  Vickers  Project  Manager 

Hewlett  pochard  Research  Laboratories  Bristol.  UK 

We  de.scribe  work  to  combine  the  tool  integration  facilities  offered  by  two  of  the  most  mature 
CASE  integration  technologies:  PCHIE  and  Hewlett  Packard's  SoftBench  product 
We  have  re-implemented  tire  Softbench  Broadcast  Message  Server  on  top  of  PCTE,  to  produce  an 
open  frameworic  that  provides  control  and  data  integration.  By  an  'open*  framework,  we  mean  one 
that  is  standards-based  and  offers  a  member  of  options  for  moving  existing  tools  to  the  framework. 

The  ENTERPRISE  H  Environment 

Dr  Amaury  Legait  Head  of  Department 

SYSECA,  France 

During  the  development  of  ENTREPRISE II  we  used  PCTE  as  the  data  integrator.  ENTREPRISE 
II  provides  more  services  than  PCTE:  dyruunic  and  static  configuration  management,  project 
management,  etc.  The  experience  gained  in  integrating  tools  in  a  PCTE  based  environment,  allows 
us  to  define  integration  paths  and  integration  levels. 

12.00  -  13.30  Lunch 
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13.00  -  13.20  Speakers' Meeting  (Secretariat) 

13  JO  Tool  Integration 

Mr  Bryan  Basdell  Manager 

Software  Engineering  Consultancy 

SD-Scicon,  UK  _ 

Issues  of  Tool  Integration  Being  Considered  in  PCTE-t-  Implementation  Hosted  on  VAX/VMS 
STAR:  the  Requirements  Analysis  Environment 

DrAytUlErgil  Associated  Professor 

Bogazicl  University  dt  STFA  SavrotUk  (Tu) 

Early  feedbacks  from  the  assessment  phase 

Mr  Girard  Boudier  RAD  Department  Manager 

Emeraude,  France 

A  short  presentation  of  the  assessment  phase  (participants  and  activities)  and  overview  of  its  first 
available  results. 

15.00  -  15.30  Tea  Break 

15  JO  Porting  Arcs  to  PCTE,  Practical  Experiences 

Mr  Anders  Lundh/ist  System  Design  Engineer 

Telia  Research,  Sweden 

The  presentation  shows  that  despite  the  fact  that  a  rather  simple  approach  has  been  followed,  a 
number  of  substantial  advantages  have  been  achieved  when  using  PCTE. 

The  AdaNICE  Toolset 

Mr  F.  Gallo  Software  Engineering  RAD  Manager 

Intecs  Sistemi  SpA,  Italy 

AdaNICE  is  a  set  of  tools  which  is  available  as  a  stand  alone  commercial  product  on  platforms 
such  as  SUN,  DEC,  HP  woikstations  and  on  PCTE  1 .5  (Emeraude).  It  is  teing  ported  on  PCTE-f  in 
the  context  of  the  TA  B  CTP. 

16.30  -  1635  Qoslng 

17.00  Bus  departs  to  Central  Station 


TNO  report 


f 


Appendix  B  Page 

B.l 


APPENDIX  B 


LIST  OF  PARTICIPANTS 


TNO  report 


Appendix  B 


Page 

B.2 


Abbatangelo,  Lt  Cdr.  G. 

Ministero  Marina-Navalcostarmi 

Italy 

Agema,  Mr  W.A. 

Koninklijke  Luchtmacht 

The  Netl^rlands 

Aldis,  Ms.  M.J.* 

Syntagma 

United  Kingdom 

Andrd,  MrE.* 

SEMA  Group 

France 

Antippas.  Mr  E. 

Alpha  Sai 

Greece 

Argento,  Mr  A. 

Digital  Engineering 

Italy 

Baldwin.  Mr  A.P. 

U.K.MOD(PE) 

United  Kingdom 

Barry,  Dr  B. 

Object  Technology  International  Inc. 

Canada 

BasdeU.MrB.W.* 

SD-Scicon 

United  Kingdom 

Belderbos,MrC.M.N, 

TNO-DO 

The  Netherlands 

Bdrubd.MrJ.* 

Orsand  Ltd. 

Canada 

Bhat,  MrB.P.* 

Heuristix  systems  Pvt  Ltd 

India 

Black.  Mr  E. 

Atherton  Technology 

USA 

Blom.  MrR.N.M. 

Ocd-Nedeiland  BV. 

The  Netherlands 

Bogaards.  Dr  K. 

Information  Technology 

Architecture  BV 

The  Netherlands 

Bond.  Ms.  S.G. 

RSREDRAMoDUK 

United  Kingdom 

BostrBm,  Mr  A. 

ELLEMTEL  Telecom  Sys.  Labs. 

Sweden 

Boudier,  MrG.* 

Gie  Emeraude 

France 

Bourguignon.  Mr  J.P.'*' 

SFGL 

France 

Bruso,  Ms.  K.L. 

UNISYS 

USA 

Cakir,  Ms. 

MoD,  Turkey 

Turkey 

Campbell,  Mr  l.G.* 

Emeraude.  Syseca 

France 

Camus,  Mr  J.L. 

Verilog 

France 

Cayaae,  Mr  0. 

Coielis 

France 

Cochran,  Mr  R.* 

Catalyst  Software 

Ireland 

Colyn  Devardiere,  Mr 

France 

Cureton,  Mr  W.H. 

Sun  Microsystems 

USA 

David.  Mr 

TRT-Philips 

France 

Davis.  MrH.F.* 

ICL 

United  Kingdom 

de  Greef,  Mr  B.L. 

Philips  Research 

Germany 

de  Hartog.  Mr  J.A. 

Digital  Equipment  BV 

The  Netherlands 

de  Jong,  Mr  S. 

NLR 

The  Nedierlands 

de  Pagter,  Mr  P  J. 

NLR 

The  Netherlands 

Deminas.  Col.  I. 

MoD,  Turkey 

Turkey 

Demiame,  Prof.  J.C.* 

CRIN 

Fraru% 

Didelot.MrF. 

THOMSON  SINTRA  ASM 

France 

Downes,  Ms.  V.A. 

OVUM  Ltd 

United  Kingdom 

DuU.MrJ.P. 

Uniface 

The  Netherlands 

Duval,  MrS. 

Verilog 

France 

Erba,  Ms.  A. 

Lombardia  Informadca 

Italy 

Ergil,  Prof.  A.E.* 

STFA  Savroriik  A.S. 

Turkey 

TNO  report 


Appendix  B 


Page 

B.3 


Fikkcit.MrD.W* 

TNO-FEL 

The  Netherlands 

Fischaleck,  Ms.  M. 

lABO 

Germany 

Florijn.  Mr  G.H. 

SERC 

The  Netherlands 

OaUo.MrR* 

Intecs  Sistemi  SpA 

Italy 

Gladman.  Dr  B.R.* 

Ministry  of  Defence 

United  Kingdom 

Gouin,  Mr  D. 

Defence  Research  Establishment 
Valcarder 

Canada 

Orambeit,  Mr  A. 

Hewlett  PackardA>SE  marketing 

Germany 

Grant.  Mr  T.J. 

BSO/Aerospace  &  Systems  BV 

The  Netherlands 

Haertel,  Mr  F. 

MOD  Germany 

Germany 

Harris.  MrP.* 

IPSYS  Software  PLC 

United  Kingdom 

Hayasbi.  Mr  K. 

SRAInc. 

Japan 

Hayter.  Mr  K 

RSRE 

United  Kingdom 

Hijwegen.  Mr  A. 

Data  Sciences  BV 

The  Netherlands 

Hirdes.  MrF.P. 

Techforce  BV 

The  Netherlands 

Hodgson,  Mr  R. 

IDE 

United  Kingdom 

Hurst,  Mr  D. 

Vista  Technologies,  Inc. 

USA 

Ijuin,  Mr  I. 

Software  Research  Associates,  Inc. 

Japan 

Imber.MrM.P.F.* 

LBMS 

United  Kingdom 

Jimmink,  Mr  R.A. 

PTT  Research 

The  Netherlands 

Kelter,  Prof.Dr  U.* 

FemUniversitAt,  Gesamthochschule 

Germany 

Kent,  Ms.  J.A. 

Syntagma 

United  Kingdom 

Keus,  Mr  H.E.* 

Westmount  Technology 

The  Netherlands 

Kirby,  MrM.W.* 

SD-Scicon  UK  Ltd. 

United  Kingdom 

Kishida,  Mr  K. 

SRA  Inc. 

Japan 

Koolma,  Dr  R.D. 

TNO-FEL 

The  Netherlands 

Kotsakis,  Mr  G. 

National  Defence  Research  Center 

Greece 

Kramer.  Mr  J.F.* 

Darpa 

USA 

Kutluoglu,  Mr  S.F. 

STFA  Savronik  Inc. 

Turkey 

Laagland,  Mr  P.J. 

BSO/Aerospace  &  Systems 

The  Netherlands 

Legait.  Dr  A.* 

Syseca 

France 

Leung,  Ms.  R. 

Bellcore 

USA 

Lewis,  Mr  G.R. 

Sun  Microsystems  Inc. 

USA 

Lichtenliein,  Mr  M. 

SFGL 

France 

Longden,  Wing  Cdr.  D.A. 

UK  Mod  (PE) 

United  Kingdom 

Luijten,  Mr  B.F.M. 

TNO  Building  and  Construction 
Research 

The  Netherlands 

Lundkvist,  Mr  A.* 

Telia  Research 

Sweden 

MMgaard,  Mr  H. 

CRI 

Denmark 

Mager.MrJ.W.L.J. 

TNO-FEL 

The  Netherlands 

Magrassi,  Dr  P. 

Gartner  Group 

Italy 

Matsumoto,  Dr  Y. 

Kyoto  University 

Japan 

I-NO  report 


Appendix  B 


Page 

B.4 


Matsumura,  Mr  Y. 

SRAlnc. 

Japan 

Matsuo,  Mr  M. 

Software  Research  Associates  Inc. 

USA 

Mattsson,  Mr  H. 

EUemtel  Telecom  Systems  Labs 

Sweden 

McLean.  Mr  C.F. 

Groupe  Bull 

USA 

Memmi,  Dr  G.* 

Groupe  Bull 

USA 

Messenio.  Ms.  N. 

Bull  Italia 

Italy 

Metaireau,  Mr  G. 

(X31  -  Informatique 

France 

Minot,  Mr  R.* 

GIE  Emeraude 

France 

Moignot.  Ms.  M. 

SFGL 

France 

Monttniny.  MrP. 

DMR  Group  Inc. 

Canada 

Momon,  MrM.W.* 

BNR  Europe  Ltd. 

United  Kingdom 

Mulder,  Mr  W. 

Hollandse  Signaalapparaten  BV 

The  Netherlands 

Nieuwenhuis,  Dr  C.H.M. 

Hollandse  Signaalapparaten  BV 

The  Netherlands 

Oliver,  Dr  H.E. 

Hewlett  Packard  Labs.  Bristol 

United  Kingdom 

Oren,  DrT.I. 

University  of  Ottawa 

Canada 

Pasquali,  Dr  V.V. 

ICL 

United  Kingdom 

Penot,  Mr  G. 

DETN  -  SIMA 

France 

Petry,  Dr 

AEG  Electrocom 

Germany 

Pitette,  Mr  G. 

SFGL 

France 

Post,  Cdr.  (WE)  J.H. 

KM/CAWeS 

The  Netherlands 

Purvis,  Mr  K.O. 

ERA  Technology 

Uidted  Kingdom 

Ragsdale,  Mr  J. 

SofTech, Inc. 

USA 

Rankin,  Mr  R.M. 

Defence  Research  Agency 

United  Kingdom 

Ratcliffe.DrM* 

University  College  of  Wales 
Aberystwyth 

United  Kingdom 

Rau,  MrH.G.* 

GPPmbH 

Germany 

Remkes,  Mr  D. 

SofTech,  Inc. 

USA 

Riddle.  MrW.E. 

SDA  inc. 

USA 

Roach,  Mr 

Digital  Equipment 

France 

Rogers,  Mr  M.W. 

CEC 

Belgium 

Rooijers,  Mr  A.J.Th. 

TNO-FEL 

The  Netherlands 

Koubine,  Dr  0. 

Verdix 

France 

Sagols.  Mr  G.* 

IBM 

France 

Sasaki,  Kir  H. 

CEO 

Japan 

Sclunidt,  Mr  U. 

BWB 

Germany 

Schouten,  MrG.S. 

Icim 

The  Netherlands 

Schravesande,  Mr  J. 

TNO-m 

The  Netherlands 

Schuberth.  Dipl.  Math.  L. 

FFM/RSP 

Germany 

Shate,  Mr  D. 

Digital  Equipment  Coip. 

Germany 

Simon,  Mr  D. 

CNES.TE/IS/MIS/PA 

France 

Solomond,  Dr  J.P. 

Ada  Joint  Program  Office 

USA 

Soufilet,  Mr  D. 

Emeraude 

France 

TNO  report 


Appendix  B 


Page 

B.S 


Spohr,  Mr  P  * 

TNO-FEL 

The  Netherlands 

Streef.  LlCoI.  J. 

MoD  ML  (DEBKIVDCAWACO) 

The  Netherlands 

Suarez,  Mr  N. 

Isdefe 

Spain 

Szymanski,  Mr  R. 

US  Air  Force 

USA 

Talbot,  Mr  D.E* 

CEC 

Belgium 

Tatge,  Mr  0.* 

Hewlett  Packard 

USA 

Thalman,  Mr  G. 

Hewlett  Packard 

USA 

Thomas,  MrM.I. 

Hewlett  Packard 

USA 

Thomley,  Mr  J.P.* 

British  Aerospace 

United  Kingdom 

Tillson,  Mr  T. 

Hewlett  Packard 

USA 

Tily,  MrC.N.J. 

UK  MOD  (PE) 

United  Kingdom 

Treumiet,  Mr  W. 

TNO-FEL 

The  Netherlands 

van  den  Berg,  Mr  F. 

Tasking  BV 

The  Netherlands 

van  den  Broek,  Mr  G.H.M. 

Philips  Research  Laboratories 

The  Netherlands 

van  der  Ham,  Kol.  B.P. 

HWO-KL 

The  Netherlands 

van  Geest,  Mr  L.F. 

KM/CAWeS 

The  Netherlands 

van  Goeverden,  Mr  W. 

DEBKUDCAWACO 

The  Netherlands 

van  Hoek,  Mr  E.A.* 

DWOO 

The  Netherlands 

van  Kats,  Mr  J.M. 

Convex  Computer  BV 

The  Netherlands 

van  Oosterom,  Mr  N.E. 

TNO-m 

The  Netherlands 

Vargenau,  Mr 

Alcatel  Alsthom  Recherche 

France 

Veibcek,  Mr  H.M.W. 

Technische  Universiteit  Eindhoven 

The  Netherlands 

Vemocchi,  Mr  L.* 

Digital  Equipment  Co. 

Italy 

Vickers,  Mr  P.A.* 

Hewlett  Packard  Labs.  Bristol 

United  Kingdom 

Vogel,  MrT. 

TNO-rri 

The  Netherlands 

Voorman,  Mr  O.J. 

Philips  Research  Laboratories 

The  Netherlands 

Walker,  Mr  G. 

Alcatel 

France 

Walsh,  Ms.  D. 

Intecs  Sistemi 

Italy 

Wareham,  Mr  P.E. 

SD-Scicon 

United  Kingdom 

Wijers,  Mr  G.M. 

SERC 

The  Netherlands 

Wohlschlegel,  Mr  W. 

CEC 

Belgium 

Wybolt,MrN. 

Cadre  Technologies  Inc. 

USA 

Zeriauth,  Mr  P. 

Alcatel  Business  Systems 

France 

Zinkiewicz,  Ms.  M. 

DMR  Group  Inc. 

Canada 

^Speaker 


TNOraport 


Appendix  C 


Page 

C.l 


Opening  Address  PCTE  '91 

(25-27  September  1991  in  The  Hague) 
by 

Mr.  P.  Spohr 
Director 

TNO  Physics  and  Electronics  Laboratory 


TNO  report 


App«ndix  C 


Page 

C.2 


I.  INTRODUCTION  C.3 

li.  OPEN  SYSTEMS  C.4 

III.  SHIFT  FROM  TECHNOLOGY  PUSH  TO  MARKET  PULL  C.6 

IV.  USER  REQUIREMENTS  C.7 

V.  CONCLUSION  C.8 


TNO  report 


Appendix  C 


Page 

C.3 


I.  INTRODUCTION 
Ladies  and  Gentlemen, 

it  is  iriy  pleasure  to  welcome  you  at  PCTE  *91. 1  am  particularly  pleased  that  the  interest  for  this 
conference  is  well-spread  over  16  different  countries  from  Europe,  North  America  and  the  far 
east. 

What  I  want  to  do  is  to  present  some  thoughts  grouped  into  three  different  topics  that  perhaps  will 
help  you  to  view  PCTE  from  three  different  angles.  The  topics  are: 

1.  Open  systems 

2.  Technology  Push  and  Market  Pull 

3.  User  needs  at  a  management  level 

These  thoughts  are  largely  motivated  by  the  fact  that  TNO-FEL  is  an  advanced  user  of  System 
Engineering  technologies  in  research  projects  in  the  areas  of: 

-  Observation  Systems 

-  Information  Technology  and  Telecommunication  Systems 
•  Trainers  and  Simulators 

-  Policy  Support  Studies 

Alltogether  TNO-FEL  has  some  200  scientist  applying  Information  and  Telecommunications 
Technology.  Of  course  we  produce  IT,  but  not  in  tire  area  of  systems  engineering. 

In  short,  we  are  an  advanced  user  of  information  technology,  whose  main  business  is  research. 
And  users  arc  nowadays  closely  connected  to  Open  Systems,  which  is  the  first  topic  I  want  to 
address. 

PCTE,  in  full  "a  basis  for  a  Portable  Common  Tool  Environment”  is  an  open  system  in  the  area  of 
CASE^  It  is,  however,  difficult  to  find  matching  definitions  of  open  systems.  DMR  group  Inc., 
for  example,  defines  Open  Systems  as  commonly  available  products  and  technologies  that  comply 
with  industry-wide,  vendor-independent  standards.  One  of  the  earliest  examples  of  course  is  the 
ISO-OSI  model  and  its  protocols. 


^  CASE;  Computer  Aided  SoAwiie  Eii|ineennc 
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Before  I  continue,  first  I  would  like  to  start  with  some  simple  definitions. 

A  user  in  my  talk,  and  probably  in  the  context  of  this  conference,  is  the  person  who  uses 
methods,  tools  (or  SEEs^)  and  many  other  skills  to  build  apfdicadons.  Those  applications  are 
delivered  to  a  client.  The  client  hopefully  has  people  around  who  use  the  application.  Those 
people  are  called  end-users. 

The  next  definition  defines  open  systems:  a  system  is  open  if  its  interfaces  are  published,  not 
counting  the  publication  of  its  user  interface. 

The  last  definition  defines  smart  buyers;  a  smart  buyer  includes  life-cycle  costs  rather  than 
the  acquisition  price  in  his  decision  to  purchase  a  system.  Quality,  maintenance, 
enhancements,  supplier  independence  and  disposal  are  important  terms  for  a  smart  buyer. 

n.  OPEN  SYSTEMS 

At  least  three  types  of  open  systems  fit  the  definition: 

P-type:  A  Proprietary  Open  System  is  a  proprietary  system  the  interfaces  of  which  are  published. 
Everyone  can  build  upon  these  published  interfaces.  IBM's  SAA^  including  AD/Cycle"*  is  an 
example,  but  examples  from  the  other  participating  companies  in  the  industrial  session  of 
this  morning  could  probably  be  given  just  as  well. 

D-type:  De  facto  Open  Systems  are  Defaced  standard  systems  to  which  many  products  comply. 
The  system,  however,  is  still  proprietary.  The  interfaces  are  "De  facto"  published  and 
sometimes  infiuenced  by  groups.  Unix  (before  Unix  International  was  formed)  and  DOS 
(proprietary)  are  prime  examples. 

S-type:  Standardized  Open  Systems  are  systems  of  which  the  interface  is  agreed  upon  and 

standardized  by  groups  (users  and/or  suppliers)  or  standardization  bodies.  A  standardization 
body  does  not  sell  a  standard  compliant  system,  a  group  might  also  sell  such  a  system. 

PCTE,  OSI,  X/Open,  OSF/1,  POSIX  and  grtq^hics  standards  like  PHIGS  and  GKS  are 
examples. 


^Software  Er,|ineerin|  Envircnmoit 
^  SAA;  SyMemf  Applicaiiont  Archiieciun 
^  AD:  Apfriication  Develatmcni 
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Even  if  you  do  not  agree  with  the  deflnition,  you  probably  will  agree  with  some  of  the  advantages 
open  systems  have.  Aocordiitg  to  a  Price  Waterhouse  study,  European  managers  eiqject  lower 
costs,  better  value  for  money  and  a  larger  choice  of  suppliers  by  1996.  Based  on  that  study,  the 
advantages  of  open  systems  are: 

-  Portability  (of  applications) 

‘  Value  for  Money 

-  Scalability  (grow  when  needed) 

-  Flexibility  (in  choice) 

-  IntegraVibility  (of  multi  vendor  components) 

It  is  often  forgotten  that  open  systems  have  advantages  for  Users  as  well  as  Suppliers.  The 
suppliers  advantages  include: 

-  Less  risk  at  product  introduction 

-  Broader  base  or  larger  inidat  market 
•  More  stable  market 

Open  systems  also  have  their  challenges  (a  positive  approach  fur  disadvantages).  Based  again  on 
the  mentioned  study  the  challenges  include: 

Migration.  The  period,  problems,  risks,  costs  of  the  transition  from  proprietary  to  open 
systems. 

Standards  coverage.  In  which  area  are  standards  established  and  in  which  area  do  we  need  to 
establish  standards? 

Competitive  advantage.  How  can  a  supplier  maintain  a  Competitive  advantage  if  a  large  part 
of  systems  have  to  behave  similar? 

Conformance.  How  well  does  a  supplier's  implementation  corJorm  to  the  standard?  How 
portable  is  an  application  in  reality? 

Security.  Do  current  open  system  proposals  include  enough  security  features,  compared  to 
what  proprietary  systems  offer? 

Continuity  of  s?ippliers.  Do  the  undoubtedly  lower  profit  margins  assure  continuity  of 
suppliers? 

Human  experts.  The  study  claims  that  there  is  a  lack  of  experts  in  open  systems  area. 

PCTE  is  an  S-type  open  system.  It  is  up  to  you  tn  determine  whether  PCTE  meets  the  advantages 
and  has  tackled  the  challenges 

If  you  would  take  a  look  at  groups  involved  in  open  systems  you  would  find  that  these  groups  are 
largely  supplier  driven.  Is  this  supplier  dominatx:e  really  surprising?  Wc  as  a  user  will  never  build 
UNIX  or  PCTE.  So  we  need  suppliers  who  dare  to  invest  and  listen  to  user  needs. 

This  brings  us  to  two  forces  which  comprise  the  second  topic !  would  like  to  address:  Technology 
Push  and  Market  Pull. 


m.  SHIFT  FROM  TECHNOLOGY  PUSH  TO  MARKET  PULL 


Let's  first  estaUish  the  fact  that  both  approaches  can  be  producets  of  technology.  As  a  usi^r  I  also 
think  that  we  need  both  type  of  forces  as  producers  of  tedinology. 

Yet.  the  shift  from  technology  push  to  market  pull  (or  user  demand)  is  taking  place  in  Europe  and 
probably  around  the  world.  And  of  course  it's  fair  to  wonder  whether  all  those  new  technologies 
help  to  improve  company  results,  quality  of  our  work,  life  or  environment  to  name  just  a  few.  If 
the  improvement  cannot  b:  noticed,  the  technology  and  development  effort  is  wasted.  That's  what 
makes  technology  push  a  questionable  approach.  But  of  course  many  examples  can  be  given  that 
have  led  to  improvements 

It  is  interesting  to  sec  that  in  a  certain  held  an  almost  opposite  move  is  being  made  with  respect  to 
the  fact  that  a  user  (market)  knows  what  he  wants.  The  held  is  most  relevant  to  this  conference.  It 
is  System  Development,  specihcally  development  of  large  scale  CCIS's^. 

A  number  of  people  within  NATO  are  convinced  that  Evolutionary  Procurement  (EP)  is  a  better 
way  to  proceed  compared  to  traditional  procurement,  wliich  is  largely  based  on  the  Waterfall 
Model. 

A  user  can  not  fully  specify  what  the  system  should  do  beforehand.  The  interesting  point  is  that 
the  evolutionary  approach  should  solve  this  problem. 

Whether  you  agree  or  not  that  EP  is  useful,  facts  are: 

1 )  Traditional  procurement  has  not  given  an  acceptable  result  in  the  CClS  domain 

2)  NIAG^  has  been  asked  to  study  the  consequences  should  NATO  wish  to  use  this  approacli. 

1  would  like  to  fmish  this  topic  with  a  User  demand  (or  rather  command)  that  is  questioned  by 
many.  It  even  can  be  questioned  whether  there  is  a  market  pull.  The  keyword  here  is  Ada.  Let  me 
be  brief  We  use  Ada  for  wargames  and  in  a  test  tool.  We  think  Ada  is  a  better  language  then 
many  others  including  C. 

Again  whether  you  agree  or  not  is  not  too  in:portant  Facts  are: 

1)  Ada  is  demanded  by  the  US-DoD,  by  NATO  and  by  some  MoD's  in  Europe,  including  the 
Netherlands  shortly. 

2)  Demanding  Ada  has  resulted  in  commercial  availability  of  many  industrial  quality  Ada 
compilers. 

3)  Compared  to  C  Ada  has  no:  been  accepted  by  the  market,  despite  of  the  demandss.  It  is, 

however,  interesting  to  note  that  again  a  change  i?.  noticeaUe  this  time  for  Space  and 
Aerospace  applications.  Also  noteworthy  is  that  Xerox  has  chosen  to  use  Ada  for  its  copiers. 
That  policy  will  be  explained  on  Tri-Ada . 


^  ConuiMiHl  CMid  InfgmMUion  Syitcmt 
^  NATO  induitrinl  Advisoiy  Onnip 
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A  number  of  other  user  stimulatiotts  -with  the  exception  of  MAPyTOP  by  Boeing-  still  have  to 
occur.  Examples  include  POSIX  compliance  required  by  the  US  government  as  of  January  1992 
and,  I  believe,  MIa'^  compliance  required  by  Nii^n  Telegraph  and  Telephone,  one  the  world's 
largest  companies,  as  of  September  1992. 

For  PCTE,  the  least  we  can  do  is  to  look  and  learn  from  the  Ada  situation  and  then  take 
appropriate  action. 

IV.  USER  REQUIREMENTS 

The  last  topic  I  want  to  discuss  is  user  requirements.  Very  recently  we  have  had  a  discussion  at 
our  laboratory  about  a  standard  CASE  tool.  This  discussion  was  held  at  management  level 
(division  management  and  board  of  directors).  From  that  discussion  1  can  validate  three  well 
known  requirements  and  can  state  one  derived  requirement. 

First  point  in  the  discussion  was  that  the  FEL-divisions  use  a  diversity  of  equipment,  however,  we 
have  standardized  on  three  computer  lines.  The  requirement  here  is  tool  portability.  It  is  a  very 
clear  requirement  for  departmental  and  divisional  managers.  However,  it  may  not  be  tliat  clear  for 
an  individual  project  manager. 

Second  point  in  the  discussion  was  education.  To  be  precise:  you  have  to  distinguish  a  method 
from  a  tool  supporting  the  method.  For  example,  the  method  may  be  Yourdon  or  Ward  and 
Mellor,  tfie  supporting  tool  may  be  coming  from  many  different  tool  suppliers. 

(t  is  quite  clear  that  envirorunent  education  has  to  do  with  teaching  people  how  to  use  a  tool. 
Method  education  is  a  different  topic  and  can  be  ignored  for  the  purpose  of  this  conference. 

The  tequirement  here  is  that  we  want  tools  with  a  similar  user  interface  style:  learn  one  tool  and 
you  can  operate  most  tools.  It  certainly  helps  if  tools  use  a  common  UIMS^  to  realize  that  style. 
HM19  and  its  quality  by  the  way  is  a  main  research  area  of  another  TNO*DR  laboratory:  The 
Institute  for  Perception  (TNO-IZF). 

The  third  point  in  our  discussion  indicated  that  there  was  doubt  whether  a  single  method,  let  alone 
a  single  tool,  could  support  the  different  types  of  IT-woik  at  our  laboratory. 

In  short:  an  envirorunent  should  support  different  methods  and  thus  different  tools. 


^  Mulii  Vendor  Inieimtion  Architecture.  Spedfleuion  designed  by  •  coniortium  of  DEC,  Rijitsu,  Hitachi,  IBM  and  NEC. 
^  User  Inteifaoe  Management  Syiiem,  Le.  MOTIF,  X-«dndowi,  Open  Look,  Open  Dialogue 
^  Human  Mlachine  Interface 
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The  last  point  discussed  is  a  logical  tollow-on  of  the  first  two  and  the  fact  that  advanced  projects 
need  project  teams:  if  you  allow  different  brands  of  equipment  and  need  different  methods  and 
sui^rting  tools,  one  needs  interoperability  of  tools  in  a  heterogeneous  netwoik  to  support  teams. 
1  leave  it  to  you  to  judge  whether  those  requirements  are  met  by  the  current  Hist  generation  of 
CASE  tools.  You  also  have  to  judge  whether  you  leave  meeting  these  requirements  to  each 
individual  tool  supplier  or  to  an  architecture  like  a  PCTE  based  fiamewoik. 

V.  CONCLUSION 


Ladies  and  gentlemen,  perhaps  I  have  triggered  some  questions  for  the  panel  discussion,  in  which 
case  1  have  served  my  putpose.  From  the  comfortable  position  that  the  experts  on  the  panel  may 
have  to  answer  the  questions  I  have  triggered, 

I  Wish  you  a  fruitful  conference  and  an  enjoyable  stay  in  the  Hague  and  declare  the  first 
international  conference  devoted  to  PCTE  open. 


Thank  you  for  your  attention. 
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